Liveblocks Starter

liveblocks-starter

Liveblocks' Next.js Starter Kit — Vercel's Liveblocks Starter Kit template: rich-text documents, notes, a whiteboard and a canvas edited together in real time, with comments, mentions, notifications, sharing and organizations — running on Cloudflare Workers + Static Assets through @opennextjs/cloudflare. The realtime documents are Liveblocks rooms, in a project the owner connects after the build; the directory the kit kept as arrays in its source (users, organizations, memberships) and the session secret are in a Cloudflare D1 database provisioned by Terraform through Orun, its schema applied by migrations, 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 kit's lib/database functions keep their signatures and semantics; they read D1 now, as server functions. The site goes live with no Liveblocks project: the marketing page and the demo sign-in work, and the dashboard says how to connect one. What the baseline adds is everything needed to make a copy of it somebody else's, built the way cirrus-baseline is. See specs/epics/liveblocks-starter for the design, the milestones and the as-built status.

Instantiating a product

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

Or, once the platform's registry lists it, from the Orun console (Baselines → liveblocks-starter → Build). Two phases: 01-product creates the repository and lands the whole product as ONE pull request — intent, CI, tooling, the D1 root, the migrations, the site and its tests — and one convergence, per environment, applies the D1 database, then its migrations, then deploys the site 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 D1 root, its migrations and their runner, 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 and database names. None of this repository's machinery ships.

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

pnpm --filter @app/web db:migrate:local   # the directory, the demo users and the secret in wrangler's local D1
pnpm --filter @app/web dev                # http://localhost:3000 — the local D1 through wrangler's platform proxy
pnpm --filter @app/web preview            # wrangler dev over the built Worker, same local D1

How it maps to Vercel

How the database reaches the Worker

infra/terraform/cloudflare-d1 ──apply──► orun secret WIRING_CLOUDFLARE_D1 (stage, prod)
                                               │   (the landing's await checks it exists)
                                               ▼
infra/db-migrate  dependsOn cloudflare-d1 (enforced on main) · secretEnv WIRING_CLOUDFLARE_D1
  apply:  packages/db's runner → POST …/d1/database/<id>/query, each pending migration once
                                               ▼
apps/web  dependsOn cloudflare-d1 + db-migrate (enforced on main) · secretEnv WIRING_CLOUDFLARE_D1_<ENV>
  build:  tooling/wire/live.mjs → wrangler.jsonc with the environment's database id
          (dev, verify-only, renders the fixture) → next build --webpack → opennextjs-cloudflare
          → tooling/wire/worker-secrets.mjs: Liveblocks' keys, when the environment has them,
            to the Worker as Worker secrets

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