Introduction to Zutra
What Zutra is — a production-ready Astro SaaS template — and how to think about adopting it.
What is Zutra?
Zutra is an Astro SaaS template — a forkable codebase that ships the parts every SaaS app needs so you can focus on what’s unique to your product.
Out of the box you get a complete marketing site, an authenticated dashboard with a log viewer, full auth UI (login / signup / forgot password), a pricing section with monthly/annual toggle, an i18n layer (English + Spanish), a dark-mode theme picker, OG image generation, sitemap, RSS, and JSON-LD schemas. Every page, every layout, every component is in the repo and editable.
What Zutra is not
- Not a hosted platform — Zutra is code you own. You clone, customise, and deploy it where you want.
- Not a no-code tool — You edit
.astro,.ts,.json, and.mdfiles directly. Comfort with TypeScript and Tailwind helps. - Not a finished product — The template removes weeks of plumbing (auth UI, pricing layout, dashboard shell, design tokens). Building your product still takes work.
What’s included
| Area | What you get |
|---|---|
| Marketing | Hero, features, pricing, FAQ, testimonials, changelog, blog, contact — all wired up |
| Auth UI | Login, signup, forgot-password, success page — Supabase-ready |
| Dashboard | Sidebar nav + 4 sub-pages (overview, logs, users, settings/billing) |
| i18n | English + Spanish with full URL routing (/es/*) and hreflang tags |
| Design system | Zutra tokens (industrial dark mode, monospace accents), Tailwind v4, 8 reusable UI primitives |
| Theming | User-pickable accent colors (Indigo, Violet, …) via the floating ThemePicker |
| SEO | OG images (auto-generated per page), JSON-LD schemas, sitemap.xml, RSS, robots.txt, llms.txt |
| Integrations | Stripe (Payment Links), Supabase (auth + DB), Resend (email), Plausible / PostHog / GA4 |
Architecture at a glance
Zutra is a single Astro project with the Node SSR adapter. The directory layout is intentional:
src/
├── pages/ ← File-based routing (EN at root, ES under /es/)
├── components/ ← Astro components grouped by feature
├── layouts/ ← Layout.astro + AppLayout.astro
├── content/ ← Content collections (blog, docs, changelog, …)
├── config/ ← The files buyers edit (site.ts, pricing.ts, features.ts, …)
├── i18n/ ← en/ + es/ (5 JSON files each) + helper functions
├── lib/ ← API helpers, rate limiting
└── styles/
└── global.css ← Design tokens (the @theme block)
The rule is simple: if it’s a string, a URL, a colour, or a feature flag, it lives in src/config/. Components read from there — nothing is hardcoded.
How to think about adopting Zutra
- Don’t start from scratch — fork or clone, run
pnpm install, runpnpm dev. You’re looking at a running site in under 2 minutes. - Edit config first, not components — change
src/config/site.ts,src/config/features.ts,src/config/pricing.ts, andsrc/i18n/en/sections.json(or the relevant sub-file) before touching any.astrofile. - Replace sample content — blog posts, changelog entries, FAQ items, testimonials all live as content collections (
src/content/blog/*.md, etc.). - Wire real integrations last — Supabase project, Stripe products, Resend domain. Each has a dedicated doc in this tutorial.
Next steps
- Installation — clone, install, run dev server
- Configuration Reference — every
src/config/*.tsfile explained - Project Architecture — conventions and where things live