Factory Zero · VENTURE BACKEND TEMPLATE
Every Factory Zero venture gets its own backend: its own Worker, its own database, its own secrets, its own domain. This repository is the starting point. Click Use this template, edit one file, and the rest is wiring.
One file to edit.
src/harness.rsnames the venture, lists the modules, and picks the adapters. Everything else in the repo is the same for every venture and is kept current by the harness.
Built on the Cratefield harness (Rust, workers-rs, axum).
Cargo.toml depends on cratefield-core, the runtime, and the modules you want
src/harness.rs Harness::builder() composition for this venture ← edit this
src/lib.rs #[event(fetch)] / #[event(scheduled)] delegating to the harness
tests/harness_builds.rs asserts Harness::build() is Ok; a bad config fails `cargo test`
wrangler.toml staging + production envs, D1, rate limit, custom domain, worker-build
migrations/ generated by `fz migrations collect`, committed, never renumbered
justfile dev · check · migrate-staging · migrate-prod
smoke.sh health, ready, and a signup against a deployed URL
.github/workflows/
ci.yml fmt · clippy · test · fz doctor · worker-build --release
deploy.yml main → staging automatically; tag v* → production behind an approval gate
health.yml weekly canary against the latest harness crates
- Use this template. Name the repo
<venture>-backend. - Edit
src/harness.rs: venture name, domain, CORS origins, modules. - Databases.
wrangler d1 create <venture>-api-stagingand<venture>-api; paste the ids intowrangler.toml. - Migrations.
just migrate-stagingrunsfz migrations collectandwrangler d1 migrations apply. - Secrets per environment.
HARNESS_SECRET,RESEND_API_KEY,TURNSTILE_SECRET,ADMIN_TOKEN, set withwrangler secret put. - Mail domain. Verify
send.<domain>in Resend. The subdomain, never the apex, which carries inbound mail. - Custom domain.
api.<domain>in the production routes ofwrangler.toml. - Ship. Push to
mainfor staging. Tagv0.1.0for production.
Steps 3, 5, 6 and 7 need a human with dashboard access. Everything else runs in CI.
just dev # wrangler dev with a local D1
just check # fmt, clippy -D warnings, test, fz doctor, worker-build
Requires stable Rust with the wasm32-unknown-unknown target,
worker-build, and wrangler.
Two GitHub Actions workflows live in .github/workflows/:
ci.yml— runs on every pull request.cargo fmt --check,cargo clippy --all-targets --all-features -- -D warnings,cargo test,cargo run --bin fz -- doctor, then installs and runsworker-build --releaseto make sure the Worker actually builds forwasm32. It never runs onmainor on tags — deploys aredeploy.yml's job.deploy.yml— runs on push. A push tomaindeploys to staging automatically. Pushing av*tag deploys to production, gated behind a required reviewer (see below). Both jobs apply pending D1 migrations withwrangler d1 migrations apply DB --env <env> --remote, deploy withwrangler deploy --env <env> --var HARNESS_BUILD:<git-sha>, then runsmoke.shagainst the deployed URL, which checks/__health,/__readyand a waitlist signup, and fails the job on any unexpected status.
Cloudflare API token. Create a scoped token (not your global API key) with exactly these permissions:
- Account → Workers Scripts → Edit
- Account → D1 → Edit
- Zone → Workers Routes → Edit
Repo configuration (one-time, by a human). In Settings → Environments,
create a staging and a production environment. Add
CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID as secrets on each. On
production, add a required reviewer so tagged deploys wait for approval
— this protection rule can't be expressed in the workflow YAML, it's
configured on the Environment itself.
Runtime secrets (HARNESS_SECRET, RESEND_API_KEY, TURNSTILE_SECRET,
ADMIN_TOKEN, ...) are never set from Actions. Set them once by hand with
wrangler secret put <NAME> --env production (and --env staging for the
staging equivalents).
Template scaffolding is tracked in the issues. It depends on the harness reaching milestone M2, when the crates are on crates.io.
MIT.
