SvelteKit SaaS

sveltekit-saas

Steve Cosman's CMSaasStarter — a SvelteKit SaaS template: a pre-rendered marketing site, a blog with an RSS feed and search, a pricing page, sign-up and sign-in with Supabase Auth, an account dashboard with profile, email, password and subscription settings, Stripe Checkout and the billing portal, a contact form, and welcome and admin email through Resend — running on Cloudflare Workers + Static Assets through @sveltejs/adapter-cloudflare, with a Supabase project per environment provisioned by Terraform through Orun and its schema applied by Orun's db-migrate — and packaged as an Orun baseline: one command takes a new product from nothing to live on stage and prod, in its own repository, under its own name, in ONE landing.

The app is upstream's, page for page. What changed is where it runs and where its settings come from: one Worker serves the pages SvelteKit pre-renders from its static assets and renders the rest; the Supabase project's URL and anon key are rendered into the Worker's config per environment and inlined into its build; every secret — the service-role key, Stripe's and Resend's — is a Worker secret, read at request time. Stripe and Resend are optional: the site goes live without them and says what to connect. What the baseline adds is everything needed to make a copy of it somebody else's — built the way cirrus-baseline builds a product, in one landing. See specs/epics/sveltekit-saas for the design, the milestones and the as-built status, including every departure.

Instantiating a product

git clone --depth 1 --branch <baseline-tag> https://github.com/sourceplane/sveltekit-saas
cd sveltekit-saas
orun new --blueprint repo-blueprint.yaml --out ~/products/acme-saas --run-hooks --resume \
  --set reponame=acme-saas --set productname="Acme SaaS" \
  --set githuborg=acme-inc --set subdomain=<workers-dev-subdomain>

Or, once the platform's registry lists it, from the Orun console (Baselines → sveltekit-saas → Build). Two phases: 01-product creates the repository, mints the four brokered credentials (Cloudflare and Supabase) and lands the whole product as one pull request, whose convergence on main provisions and deploys it per environment in a fixed order —

supabase ──▶ db-migrate ──▶ web

— each edge mode: enforced on a push to main and advisory on a pull request; then 02-docs records the live deployment from probed facts. BOOTSTRAP.md is the operator guide; docs/phases/ has a page per phase.

The new repository receives the product only — the app, the Terraform root, the migrations, the tests, its CI, its tooling, a README of its own and its operating contract — renamed throughout to the product's name, repository, Worker and Supabase project. None of this repository's machinery ships. Stripe and email are the owner's to connect afterwards (the product's README, "Stripe" and "Email"): no platform brokers them, so the card asks for no Stripe or Resend key, and the site says what is missing.

What is here

Getting started

pnpm install
pnpm run wire:fixture   # render apps/web/wrangler.jsonc from the offline fixture
pnpm typecheck
pnpm lint
pnpm test
pnpm build              # vite build → apps/web/.svelte-kit/cloudflare (the Worker and its assets)

To run it against a Supabase project of your own (a free one, or the stage project a bootstrap created):

cd apps/web
cp .env.example .env              # PUBLIC_SUPABASE_URL and PUBLIC_SUPABASE_ANON_KEY
cp .dev.vars.example .dev.vars    # PRIVATE_SUPABASE_SERVICE_ROLE (and Stripe, Resend: optional)
pnpm dev                          # http://localhost:5173

pnpm build and pnpm preview (wrangler dev over the build) read the project from wrangler.jsonc instead, so render it with your project for a local build of your own, or leave the fixture for the offline checks. A project of your own needs the schema: run the migrations in packages/db/src/migrations in order in its SQL editor, or let a bootstrap's db-migrate apply them.

Stripe

Billing is off until an environment has a Stripe secret key:

1. Create the products and prices in Stripe and put their ids in apps/web/src/routes/(marketing)/pricing/pricing_plans.ts (stripe_price_id, stripe_product_id), as upstream's README describes.
2. Store the secret key as the product's Orun secret STRIPE_API_KEY for the environment (orun secrets set STRIPE_API_KEY --env stage, or the console's Secrets) and redeploy it (Orunbase's Deploy button, or Run workflow on main).

The build hands the key to the Worker as a secret (tooling/wire/worker-secrets.mjs, the value over stdin, never in a bundle); the billing page then opens Stripe Checkout and the billing portal. Until then it says Stripe is not connected, and checkout and the portal send visitors there. Removing the Orun secret does not remove the Worker's copy: wrangler secret delete PRIVATE_STRIPE_API_KEY --name <worker> too.

Email

Welcome and admin emails go through Resend once an environment has RESEND_API_KEY, ADMIN_EMAIL (where admin notices go) and FROM_ADMIN_EMAIL (a sender on a domain verified in Resend) as Orun secrets; redeploy after setting them. Without them no email is sent, as upstream behaves.

Supabase Auth's own email (confirmation, password reset) is the project's: a new project's built-in SMTP mails only its organization's members, so the Terraform root turns email confirmation off (authEmailConfirmation: "false" in infra/terraform/supabase/component.yaml) and sign-up signs the user straight in. Give the project SMTP of its own (Supabase → Authentication → SMTP), then set it to "true"; the next apply turns confirmation on.

OAuth providers

The sign-in page offers email and password. To add GitHub (upstream's default), create a GitHub OAuth app whose callback is https://<project-ref>.supabase.co/auth/v1/callback, turn the provider on in the environment's Supabase project (Authentication → Providers), and add "github" to oauthProviders in apps/web/src/routes/(marketing)/login/login_config.ts.

Custom domain

Each environment answers on its workers.dev URL. To serve one on a domain of your own, attach the domain to the Worker in Cloudflare (Workers → the Worker → Domains & Routes), then set SITE_URL under that environment's env: in intent.yaml and merge: the next apply points the project's Auth at it, and the next deploy builds the sitemap, the feed and the emails on it. BASE_DOMAIN in intent.yaml holds the placeholder <repo>.example.com until then.

How it maps to adapter-auto and Vercel

How the project reaches the Worker

infra/terraform/supabase ──apply──► WIRING_SUPABASE (url, anon key) · SUPABASE_SERVICE_ROLE_KEY
                                    · SUPABASE_PROJECT_REF · SUPABASE_DB_PASSWORD · SUPABASE_DB_URL
        ▼
infra/db-migrate  dependsOn supabase (enforced on main)
  apply:  packages/db's runner → POST api.supabase.com/v1/projects/<ref>/database/query, each pending migration once
        ▼
apps/web  dependsOn supabase + db-migrate (enforced on main) · secretEnv WIRING_SUPABASE_<ENV>
  build:  tooling/wire/live.mjs → wrangler.jsonc vars → vite build (the project inlined)
          → worker-secrets.mjs: the service-role key, Stripe and Resend as Worker secrets
  smoke:  / renders to </html>; /api/health counts profiles with the service-role key

wrangler.jsonc is committed as the fixture render of wrangler.template.jsonc, because the deploy lane's verify-app-structure step checks the config exists before it builds.

CI

Licence

CMSaasStarter is © 2023 Steve Cosman, under the MIT License (apps/web/LICENSE). The port keeps it.