A Supabase-backed static CMS starter for Astro
How this site uses Supabase as a small content backend while still deploying as a fast static Astro site.
A static site does not have to mean hardcoded content forever. The pattern I like for small portfolio and marketing sites is simple: use Supabase as the content source, fetch published rows at build time, and ship static HTML.
The model is intentionally small. Journal posts and work projects live in Postgres tables. Public visitors can only read published rows through RLS policies. Drafts stay out of the static build until they have a publish date and published status.
Astro handles the build. During static generation, it asks Supabase for published content, converts Markdown to HTML, and creates routes for each slug. The deployed site is still static, so it stays fast, cacheable, and SEO-friendly.
I also keep bundled fallback content in the repository. That gives local development a safety net if the database is unavailable, and it makes deploy previews less fragile while content migrations are being applied.
The tradeoff is rebuild timing. If content changes in Supabase, the static site needs a new build to reflect it. For a personal site, portfolio, or small editorial surface, that is usually a good trade: simpler hosting, better performance, and fewer runtime failure modes.
The important part is not Supabase specifically. The important part is choosing the smallest content architecture that matches the publishing workflow. For this site, build-time content is enough.