Platforms

platforms-starter-kit

Vercel's Platforms Starter Kit — a multi-tenant app where every tenant is a subdomain (acme.yourdomain.com), created from a landing form with an emoji, listed and deleted from /admin — running on Cloudflare Workers + Static Assets through @opennextjs/cloudflare, with the tenant records in a Workers KV namespace provisioned by Terraform through Orun, 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; the store is KV behind the Upstash client's surface instead of Redis, and a tenant is served by path (/s/<tenant>) on any host that is not its root domain, so a fresh deploy works on workers.dev before a custom domain exists. What the baseline adds is everything needed to make a copy of it somebody else's, built the way cirrus-baseline is since its one-landing bootstrap. See specs/epics/platforms-starter-kit for the design, the milestones and the as-built status.

Instantiating a product

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

Or, once the platform's registry lists it, from the Orun console (Baselines → platforms-starter-kit → Build). Two phases: 01-product creates the repository and lands the whole product as ONE pull request — intent, CI, tooling, the KV root, the app and its tests — and one convergence applies the KV namespace on stage and prod and then deploys the app with its id; 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, its KV root, its tests, its CI, its tooling, a README of its own and its operating contract — renamed throughout to the product's name, repository, Cloudflare Worker, namespace titles and root domain. None of this repository's machinery ships.

It goes live on workers.dev: the landing page, creating a tenant, the tenant's page at /s/<tenant> and /admin all work there. Tenant SUBDOMAINS need a root domain on a Cloudflare zone with a wildcard route to the Worker — the owner's step after the bootstrap, described in the product's README. The console does not ask for it: a product is born with the reserved placeholder <reponame>.example.com as its root domain (BASE_DOMAIN), and that step replaces it with the owner's.

What is here (the product)

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              # next build + opennextjs-cloudflare build → apps/web/.open-next

pnpm --filter @app/web dev        # http://localhost:3000, tenants at http://<tenant>.localhost:3000
pnpm --filter @app/web preview    # wrangler dev over the built Worker, tenants at /s/<tenant>

Both get a local KV namespace from wrangler, no account needed. The root domain is NEXT_PUBLIC_ROOT_DOMAIN (localhost:3000 when unset; see apps/web/.env.example).

How it maps to Vercel

There are no secrets: the KV namespace is a binding, and the template's admin page has no authentication (upstream's TODO; Cloudflare Access in front of /admin is the zero-code gate). .dev.vars.example is empty on purpose.

How the namespace id reaches the Worker

infra/terraform/cloudflare-kv ──apply──► orun secret WIRING_CLOUDFLARE_KV (stage, prod)
                                               │   (each deploy resolves it as it starts;
                                               │    a missing one fails the lane)
                                               ▼
apps/web  dependsOn cloudflare-kv (enforced on main) · secretEnv WIRING_CLOUDFLARE_KV_<ENV>
  build:  tooling/wire/live.mjs → wrangler.jsonc with the environment's namespace id
          (dev, verify-only, renders the fixture) → next build (BASE_DOMAIN) → opennextjs-cloudflare

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; testing/e2e.test.sh fails if the two disagree.

CI