next-forge

next-forge

Vercel's next-forge — a production-grade SaaS Turborepo: the app (a dashboard behind Clerk, with search, a webhooks portal, live cursors and notifications), the marketing site (home, pricing, a blog, legal pages and a contact form, in six languages) and the API (Stripe and Clerk webhooks, health, a daily keep-alive) over twenty shared packages — running on Cloudflare Workers + Static Assets, one Worker per app through @opennextjs/cloudflare, with its database a Supabase project's Postgres reached through Cloudflare Hyperdrive, files in R2, the contact form's rate limit in Workers KV and the keep-alive as a Cron Trigger, all four provisioned by Terraform through Orun and the 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 template's code is the code. What the port changes is what the Workers runtime, Workers Free's 3 MiB per Worker and a fresh, unattended deployment force: Prisma's client becomes the same database.page calls over postgres.js through Hyperdrive, Vercel Blob becomes R2, Upstash becomes KV, Vercel Cron a Cron Trigger, the Sentry and BetterStack SDKs Workers Logs, and every SaaS — Clerk included, which upstream requires — becomes optional, so the three Workers deploy and serve before their owner has signed up for any of them. Vercel's next-forge is MIT-licensed (LICENSE). See specs/epics/next-forge 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/next-forge
cd next-forge
orun new --blueprint repo-blueprint.yaml --out ~/products/acme-forge --run-hooks --resume \
  --set reponame=acme-forge --set productname="Acme Forge" \
  --set githuborg=acme-inc --set subdomain=<workers-dev-subdomain>

Or, once the platform's registry lists it, from the Orun console (Baselines → next-forge → Build). Two phases: 01-product creates the repository, mints the six 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 ──▶ cloudflare-hyperdrive ──▶ db-migrate ──▶ app, api
cloudflare-r2 ──▶ app            cloudflare-kv ──▶ 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 three apps, the packages, the Terraform roots, 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, Workers, Supabase project, Hyperdrive config, bucket and namespace. None of this repository's machinery ships. The SaaS keys are the owner's to store afterwards (the product's README, "Connecting a service"): no platform brokers them, so the card asks for none.

What is here (the product)

Getting started

pnpm install
pnpm run wire:fixture   # re-render each apps/*/wrangler.jsonc from its template (they are committed)
pnpm typecheck
pnpm lint
pnpm test
pnpm build              # next build --webpack + opennextjs-cloudflare build → apps/*/.open-next

Running it locally, deploying, connecting each service and the custom-domain step are the product's README, .baseline/product/README.md.

How it maps to Vercel

CI