FACTORY ZERO

TECHNOLOGY / OPEN SOURCE

Ordinary parts. Assembled once.

Every venture needs a backend, and none of them should build one. The parts a company needs to exist are written once, as an open-source harness in Rust. A venture picks the modules it wants, wires them in one file, and ships as a single stateless worker with its own database.

GITHUB.COM/CRATEFIELD/HARNESS →

The factory in numbers

ventures
2317 validation · 1 prototype · 5 launch
on the stack
17of 23 ventures, the shared parts
open source
118 MIT · 3 Apache-2.0
run on the harness
1818 live today · 1 planned
decision records
30in the harness repository

HOW A VENTURE IS BUILT

One file names the company.

A venture backend is a small Rust project. It lists the modules it uses, the adapters that connect them to the world, and the venture’s own name and domain. Everything else is the harness. Build it and the result is one worker that contains exactly those modules and nothing else.

If a module needs something the runtime cannot provide, or two modules claim the same table, the build fails before anything is deployed. A misconfigured venture cannot reach production.

Harness::builder() .venture(Venture::new("factory0", "factory0.ventures") .cors_origins(["https://factory0.ventures"])) .module(EmailSignup::new().double_opt_in(true)) .module(Waitlist::new() .products(["kontinuum", "undercover-rockstars"])) .runtime(Cloudflare::new() .db("DB") .mailer(Resend::from_env()) .captcha(Turnstile::from_env())) .build()?
  1. Step 1

    Name it

    The venture, its domain, its modules and the adapters that answer for them. One file.

  2. Step 2

    Compose it

    The build refuses a module whose port the runtime does not provide, and two modules that claim the same table or route.

  3. Step 3

    Ship it

    One stateless worker containing exactly the listed modules, with its own database, secrets and domain.

THE LAYERS

Six layers, from the runtime up to the products.

Read from the bottom up: where code runs, the harness every backend is compiled from, the backends, the shared products, the agents that run the company, and the standalone ventures. Solid chips are live today, outlined chips are in the harness, dashed chips are planned.

01RUNTIME

Cloudflare Workers, compiled to WebAssembly

Where every venture worker runs. Data and mail sit beside it, and the same code can run on a server.

Workers (wasm32)D1 databaseResend mailKVTurnstileRate limitingPostgres, native runtime
02HARNESS

Cratefield: the open-source Rust core

Ports, the router and the modules. A module asks for a port; an adapter answers.

Cratefield

Ports

DatabaseMailerCaptchaRateLimiterKeyValueSigner

Modules

email-signupwaitlist
03BACKENDS

One worker and one database per venture

Each venture is composed from the harness and deployed on its own. Live on the harness today:

ColonizerFindsYou.workSupportGeniuspromptdecodeGroove GuruPosPluginKeep ShippingOwlpostBloodrankratecla.imSealbinrelease.showLiving BrainShoalTokkerLedgersGhostwritin'SqueezinYoginini
04SHELVES

The stack: products every venture plugs into

The shared products, shelved by what they do. Each is a company with its own customers.

Ship & run

  • VibeCaddie
  • Keep Shipping
  • release.show
  • Shoal

Communication

  • Owlpost
  • Squeezin

Security

  • promptdecode
  • Sealbin

Customers

  • SupportGenius
  • PosPlugin
  • Ledgers

Content & AI

  • Kontinuum
  • Living Brain
  • Tokker
  • Ghostwritin'
05AGENTS

Five layers, one agent for each function

Each function in each layer is an agent. Colonizer runs the coding agents for the build layer.

  • DISCOVER3 agents
  • BUILD4 agents
  • OPERATE4 agents
  • DISTRIBUTE3 agents
  • LEARN3 agents

Colonizer: coding agents that turn GitHub issues into pull requests

06PRODUCTS

The standalone ventures

Ventures outside the stack. They inherit the foundation and do not add to it.

Undercover RockstarsYogininiFindsYou.workGroove GuruBloodrankratecla.im

The six layers, bottom up

  1. runtime: Cloudflare Workers, compiled to WebAssembly. Where every venture worker runs. Data and mail sit beside it, and the same code can run on a server.
  2. harness: Cratefield: the open-source Rust core. Ports, the router and the modules. A module asks for a port; an adapter answers.
  3. backends: One worker and one database per venture. Each venture is composed from the harness and deployed on its own. Live on the harness today:
  4. shelves: The stack: products every venture plugs into. The shared products, shelved by what they do. Each is a company with its own customers.
  5. agents: Five layers, one agent for each function. Each function in each layer is an agent. Colonizer runs the coding agents for the build layer.
  6. products: The standalone ventures. Ventures outside the stack. They inherit the foundation and do not add to it.

A REQUEST, END TO END

Who does what, when a visitor signs up.

Drawn only from the links in the registry. A solid line is live today and carries traffic; a dashed line is planned and carries none yet.

  1. Visitor

    a person on a venture site

  2. Venture worker

    one worker per venture, on the Cratefield harness

    live

  3. Owlpost

    mail for the ventures

    live

  4. SupportGenius

    bug reports and support

    planned

  5. Colonizer

    coding agents, on the harness

    live

  6. Living Brain

    knowledge that keeps what worked

    planned

The links in this flow: Visitor to Venture worker, HTTPS request: live. Venture worker to Owlpost, confirmation mail: live. Venture worker to SupportGenius, errors become issues: planned. SupportGenius to Living Brain, support feeds knowledge: planned. Colonizer to Living Brain, agents feed knowledge: live.

Signing up on a venture, and where the message goes next. Arrows show the direction of each link; the status is the registry’s.

MODULES ONLY SEE PORTS

Ports on one side. Adapters on the other.

A module asks for a port and never a vendor. The runtime answers through an adapter. Adapters are the harness’s own; the status says where a live venture uses one today.

  • Database

    tables, queries and migrations

    • D1 (live)
    • Postgres (in the harness)
    • SQLite (in the harness)

  • Mailer

    transactional mail

    • Resend (live)
    • Owlpost (planned)

  • Captcha

    a bot check, failing closed

    • Turnstile (in the harness)

  • KeyValue

    small key-value state

    • Cloudflare KV (in the harness)

  • RateLimiter

    request budgets per key

    • Cloudflare Rate Limiting (in the harness)
    • Redis (in the harness)

  • Payments

    checkout and billing

    • Polar (planned)
    • Stripe (in the harness)

  • TextModel

    a model completion

    • Anthropic (in the harness)
    • OpenAI-compatible (in the harness)

  • Push

    notices to devices

    • APNs (in the harness)
    • FCM (in the harness)
    • Web Push (in the harness)

  • Signer

    signing by key reference

    • Turnkey (in the harness)

Ports and their adapters: Database (tables, queries and migrations): D1 (live), Postgres (in the harness), SQLite (in the harness). Mailer (transactional mail): Resend (live), Owlpost (planned). Captcha (a bot check, failing closed): Turnstile (in the harness). KeyValue (small key-value state): Cloudflare KV (in the harness). RateLimiter (request budgets per key): Cloudflare Rate Limiting (in the harness), Redis (in the harness). Payments (checkout and billing): Polar (planned), Stripe (in the harness). TextModel (a model completion): Anthropic (in the harness), OpenAI-compatible (in the harness). Push (notices to devices): APNs (in the harness), FCM (in the harness), Web Push (in the harness). Signer (signing by key reference): Turnkey (in the harness).

DESIGN RULES

Four rules the design keeps.

  • 01

    Modules only see ports.

    A module asks for a database, a mailer, a captcha. It never touches a Cloudflare binding or a vendor client. Adapters answer. That one rule is what makes the later move off Cloudflare a change of a single crate.

    moduleMaileradapter

  • 02

    Composition happens at compile time.

    No plugin loading, no registry service, no runtime surprises. The worker contains what the venture listed, and the compiler is the first reviewer. A module whose source should not enter the shared build can run as its own worker, mounted at the same path over a service binding. It is still composed, just not into the same binary.

    compilerefusedeploy

  • 03

    One venture, one database.

    Nothing is shared at runtime between companies. Each has its own worker, its own data, its own secrets. A venture can be backed up, moved or shut down without touching another.

    workerdatabasesecrets
    workerdatabasesecrets
    workerdatabasesecrets

    no runtime shared

  • 04

    Stateless by construction.

    Nothing survives a request except what is written to the database. Confirmation and unsubscribe links are signed tokens, so there is no session store to run, scale or leak.

    requestworkerdatabase

    no session store

STATUS

Where the harness is.

Progress is tracked as issues and milestones in the open.

  1. M0done

    Foundation

    Workspace tooling, core, the Cloudflare runtime, the Resend and Turnstile adapters, the SQLite adapter, the fz CLI and the testing kit.

  2. M1done

    First modules

    Email signup, waitlist, templates, the security baseline and observability.

  3. M2in progress

    First venture live

    crates.io publishing, docs, contract versioning, and the first venture on its own API domain.

  4. M3done

    Self-hosted portability

    The Postgres adapter, the native runtime, a parity suite on SQLite and Postgres, and data export and import.

DESIGN
30 decision records, all in the repository
ARCHITECTURE
12 sections in the architecture document
FIRST MODULES
Email signup and waitlist, built
PUBLISHED
Most crates are on crates.io. A release round is pending.
MANAGED SERVICE
Not built yet. The control plane is designed, not written.

Harness figures: read from Cratefield/harness on 2026-10-21.

MILESTONES →

SECURITY AND PRIVACY

Six layers between a request and the data.

Each layer is a control the harness documents. The full list is in its security and privacy documents.

  1. 01 · EDGE

    Only the venture’s own origins

    The venture’s Worker answers on its own domain. CORS allows only the origins the venture lists, and every response echoes a request id.

  2. 02 · ABUSE

    Bots and floods

    Turnstile, failing closed. Rate limits on every public write, through the RateLimiter port.

  3. 03 · REQUESTS

    Errors and logs without addresses

    Errors are problem+json with a fixed slug for each case. One structured line per request, never an email address.

  4. 04 · TOKENS

    Links, not sessions

    Confirmation and unsubscribe links are HMAC-signed, with key rotation. There is no session store to run, scale or leak.

  5. 05 · SECRETS

    Envelope encryption

    Secrets are envelope-encrypted and bound to their row. The KMS port’s local-file provider refuses production.

  6. 06 · ISOLATION

    One venture, one database

    No runtime is shared between companies. Each has its own worker, data and secrets, and can be moved or shut down alone.

SECURITY.md →   PRIVACY.md →

WHAT IS OPEN

The factory floor is public. The recipes are not.

The harness, its runtime, its adapters and the first two modules are MIT licensed and developed in the open. Anyone can build a backend on them, and every venture we run does. The modules that encode how Factory Zero operates its companies stay private. Each venture’s own backend is private too.

One venture is the harness itself. Cratefield takes the open-source harness and adds the managed layer around it: it would provision the worker, the database and the secrets inside your own Cloudflare account and then operate them. The harness is real and running; that control plane is designed and not yet written. It is also where the module boundary earns its keep: a customer can build and deploy a module of their own without the source ever reaching us.

Decisions are written down as they are made. The architecture document and the decision records are in the repository, including the one recording why a first attempt was thrown away.

Licences across the stack

Of the 17 ventures on the stack, 11 are open source, each with a public repository under an OSI licence. The bar and the tiles are drawn from the registry’s licence field.

  • KontinuumMIT
  • CratefieldMIT
  • ColonizerMIT
  • SupportGeniusMIT
  • promptdecodeMIT
  • Keep ShippingMIT
  • LedgersMIT
  • Ghostwritin'MIT
  • SealbinApache-2.0
  • Living BrainApache-2.0
  • TokkerApache-2.0
  • VibeCaddieNot open source
  • PosPluginNot open source
  • OwlpostNot open source
  • release.showNot open source
  • ShoalNot open source
  • SqueezinNot open source

Stack ventures by licence: Kontinuum: MIT. Cratefield: MIT. VibeCaddie: Not open source. Colonizer: MIT. SupportGenius: MIT. promptdecode: MIT. PosPlugin: Not open source. Keep Shipping: MIT. Owlpost: Not open source. Sealbin: Apache-2.0. release.show: Not open source. Living Brain: Apache-2.0. Shoal: Not open source. Tokker: Apache-2.0. Ledgers: MIT. Ghostwritin': MIT. Squeezin: Not open source.