Content Wind

content-wind

Vercel's Content Wind template — a personal website written in Markdown, built with Nuxt Content, Tailwind CSS and Iconify: pages with layouts, navigation generated from them, meta tags, light and dark mode, icons and highlighted code — running on Cloudflare Workers + Static Assets through Nitro's cloudflare_module preset, every page prerendered and Nuxt Content's queries on a Cloudflare D1 database Terraform provisions per environment, and packaged as an Orun baseline: one command takes a new site from nothing to live on stage and prod, in its own repository, under its own name — in ONE landing.

The port is Content Wind as upstream ships it (atinux/content-wind at f0e56c9), its app, content and look unchanged: Vercel's Nuxt hosting becomes Nitro's Workers preset, Nuxt Content's SQLite becomes the D1 binding — which Nuxt Content creates its tables in and fills from the build's dump on the first query, so there are no migrations — and the site's origin is set per environment. It is the same Nuxt Content → D1 seam as docus. What the baseline adds is everything needed to make a copy of it somebody else's, built the way turso-starter is. See specs/epics/content-wind for the design, the milestones and the as-built status.

Instantiating a product

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

Or, once the platform's registry lists it, from the Orun console (Baselines → content-wind → Build). Two phases: 01-product creates the repository and lands the whole product as ONE pull request — intent, CI, tooling, the D1 root, the site and its tests — and one convergence, per environment, applies the D1 database, 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 site and its content, its D1 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 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              # nuxt build → apps/web/.output (the Worker, and every page prerendered)

pnpm --filter @app/web dev       # http://localhost:3000 — the content in a local SQLite file
pnpm --filter @app/web preview   # wrangler dev over the built Worker, a local D1 behind DB

How it maps to Vercel

How the database reaches the Worker

infra/terraform/cloudflare-d1 ──apply──► orun secret WIRING_CLOUDFLARE_D1 (stage, prod)
                                               ▼
apps/web  dependsOn cloudflare-d1 (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) → nuxt build (NUXT_SITE_URL per environment)
  first query after the deploy: Nuxt Content creates its tables in D1 from the bundled dump

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