FACTORY ZERO

TECHNOLOGIE / OPEN SOURCE

Gewöhnliche Teile. Einmal zusammengesetzt.

Jedes Venture braucht ein Backend, und keines sollte eines bauen. Die Teile, die ein Unternehmen zum Bestehen braucht, werden einmal geschrieben, als Open-Source-Harness in Rust. Ein Venture wählt die gewünschten Module, verdrahtet sie in einer Datei und wird als ein einziger zustandsloser Worker mit eigener Datenbank ausgeliefert.

GITHUB.COM/CRATEFIELD/HARNESS →

Die Factory in Zahlen

Ventures
2317 Validierung · 1 Prototyp · 5 Launch
im Stack
17von 23 Ventures, die gemeinsamen Teile
Open Source
118 MIT · 3 Apache-2.0
laufen auf dem Harness
1818 heute live · 1 geplant
Entscheidungsprotokolle
30im Harness-Repository

SO WIRD EIN VENTURE GEBAUT

Eine Datei benennt das Unternehmen.

Ein Venture-Backend ist ein kleines Rust-Projekt. Es listet die verwendeten Module, die Adapter, die sie mit der Außenwelt verbinden, sowie Namen und Domain der Venture auf. Alles andere ist der Harness. Beim Build entsteht ein Worker, der genau diese Module enthält und nichts sonst.

Braucht ein Modul etwas, das die Laufzeit nicht liefern kann, oder beanspruchen zwei Module dieselbe Tabelle, schlägt der Build fehl, bevor etwas deployt wird. Ein falsch konfiguriertes Venture kann nicht in Produktion gelangen.

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. Schritt 1

    Benennen

    Die Venture, ihre Domain, ihre Module und die Adapter, die für sie antworten. Eine Datei.

  2. Schritt 2

    Zusammenstellen

    Der Build lehnt ein Modul ab, dessen Port die Runtime nicht bereitstellt, sowie zwei Module, die dieselbe Tabelle oder Route beanspruchen.

  3. Schritt 3

    Ausliefern

    Ein zustandsloser Worker, der genau die aufgelisteten Module enthält, mit eigener Datenbank, eigenen Geheimnissen und eigener Domain.

DIE EBENEN

Sechs Ebenen, von der Runtime bis zu den Produkten.

Von unten nach oben gelesen: wo Code läuft, der Harness, aus dem jedes Backend kompiliert wird, die Backends, die gemeinsamen Produkte, die Agenten, die das Unternehmen betreiben, und die eigenständigen Ventures. Ausgefüllte Chips sind heute live, umrandete Chips sind im Harness, gestrichelte Chips sind geplant.

01RUNTIME

Cloudflare Workers, nach WebAssembly kompiliert

Wo jeder Venture-Worker läuft. Daten und Mail liegen daneben, und derselbe Code kann auf einem Server laufen.

Workers (wasm32)D1-DatenbankResend-MailKVTurnstileRate LimitingPostgres, native Runtime
02HARNESS

Cratefield: der Open-Source-Rust-Kern

Ports, der Router und die Module. Ein Modul fordert einen Port an; ein Adapter antwortet.

Cratefield

Ports

DatabaseMailerCaptchaRateLimiterKeyValueSigner

Module

email-signupWarteliste
03BACKENDS

Ein Worker und eine Datenbank pro Venture

Jede Venture wird aus dem Harness zusammengestellt und eigenständig deployt. Heute live auf dem Harness:

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

Der Stack: Produkte, an die jede Venture andockt

Die gemeinsamen Produkte, nach ihrer Aufgabe in Regale sortiert. Jedes ist ein Unternehmen mit eigenen Kunden.

Ausliefern & betreiben

  • VibeCaddie
  • Keep Shipping
  • release.show
  • Shoal

Kommunikation

  • Owlpost
  • Squeezin

Sicherheit

  • promptdecode
  • Sealbin

Kunden

  • SupportGenius
  • PosPlugin
  • Ledgers

Inhalte & KI

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

Fünf Ebenen, ein Agent für jede Funktion

Jede Funktion in jeder Ebene ist ein Agent. Colonizer betreibt die Coding-Agenten für die Build-Ebene.

  • DISCOVER3 Agenten
  • BUILD4 Agenten
  • OPERATE4 Agenten
  • DISTRIBUTE3 Agenten
  • LEARN3 Agenten

Colonizer: Coding-Agenten, die GitHub-Issues in Pull Requests verwandeln

06PRODUKTE

Die eigenständigen Ventures

Ventures außerhalb des Stacks. Sie erben das Fundament und erweitern es nicht.

Undercover RockstarsYogininiFindsYou.workGroove GuruBloodrankratecla.im

Die sechs Ebenen, von unten nach oben

  1. runtime: Cloudflare Workers, kompiliert zu WebAssembly. Wo jeder Venture-Worker läuft. Daten und Mail liegen daneben, und derselbe Code kann auf einem Server laufen.
  2. harness: Cratefield: der Open-Source-Rust-Kern. Ports, der Router und die Module. Ein Modul fordert einen Port an; ein Adapter antwortet.
  3. backends: Ein Worker und eine Datenbank pro Venture. Jede Venture wird aus dem Harness zusammengestellt und eigenständig deployt. Heute live auf dem Harness:
  4. shelves: Der Stack: Produkte, an die jede Venture andockt. Die gemeinsamen Produkte, nach ihrer Aufgabe in Regale sortiert. Jedes ist ein Unternehmen mit eigenen Kunden.
  5. agents: Fünf Ebenen, ein Agent für jede Funktion. Jede Funktion in jeder Ebene ist ein Agent. Colonizer betreibt die Coding-Agenten für die Build-Ebene.
  6. products: Die eigenständigen Ventures. Ventures außerhalb des Stacks. Sie erben das Fundament und erweitern es nicht.

EINE ANFRAGE, DURCHGÄNGIG

Wer was tut, wenn sich ein Besucher anmeldet.

Gezeichnet ausschließlich aus den Verbindungen im Registry. Eine durchgezogene Linie ist heute live und führt Traffic; eine gestrichelte Linie ist geplant und führt noch keinen.

  1. Besucher

    eine Person auf einer Venture-Seite

  2. Venture-Worker

    ein Worker pro Venture, auf dem Cratefield-Harness

    live

  3. Owlpost

    E-Mail für die Ventures

    live

  4. SupportGenius

    Fehlerberichte und Support

    geplant

  5. Colonizer

    Coding-Agenten, auf dem Harness

    live

  6. Living Brain

    Wissen, das bewahrt, was funktioniert hat

    geplant

Die Verbindungen in diesem Ablauf: Besucher zum Venture-Worker, HTTPS-Anfrage: live. Venture-Worker zu Owlpost, Bestätigungsmail: live. Venture-Worker zu SupportGenius, Fehler werden zu Issues: geplant. SupportGenius zu Living Brain, Support speist das Wissen: geplant. Colonizer zu Living Brain, Agenten speisen das Wissen: live.

Die Anmeldung bei einer Venture und wohin die Nachricht als Nächstes geht. Pfeile zeigen die Richtung jeder Verbindung; der Status stammt aus dem Registry.

MODULE SEHEN NUR PORTS

Ports auf der einen Seite. Adapter auf der anderen.

Ein Modul fordert einen Port an, niemals einen Anbieter. Die Runtime antwortet über einen Adapter. Die Adapter gehören dem Harness; der Status zeigt, wo eine Live-Venture heute einen nutzt.

  • Database

    Tabellen, Abfragen und Migrationen

    • D1 (live)
    • Postgres (im Harness)
    • SQLite (im Harness)

  • Mailer

    transaktionale Mails

    • Resend (live)
    • Owlpost (geplant)

  • Captcha

    eine Bot-Prüfung, im Zweifel ablehnend

    • Turnstile (im Harness)

  • KeyValue

    kleiner Key-Value-Zustand

    • Cloudflare KV (im Harness)

  • RateLimiter

    Anfragebudgets pro Schlüssel

    • Cloudflare Rate Limiting (im Harness)
    • Redis (im Harness)

  • Payments

    Checkout und Abrechnung

    • Polar (geplant)
    • Stripe (im Harness)

  • TextModel

    eine Modellantwort

    • Anthropic (im Harness)
    • OpenAI-compatible (im Harness)

  • Push

    Benachrichtigungen an Geräte

    • APNs (im Harness)
    • FCM (im Harness)
    • Web Push (im Harness)

  • Signer

    Signieren per Schlüsselreferenz

    • Turnkey (im Harness)

Ports und ihre Adapter: Database (Tabellen, Abfragen und Migrationen): D1 (live), Postgres (im Harness), SQLite (im Harness). Mailer (transaktionale Mails): Resend (live), Owlpost (geplant). Captcha (eine Bot-Prüfung, die im Zweifel ablehnt): Turnstile (im Harness). KeyValue (kleiner Key-Value-Zustand): Cloudflare KV (im Harness). RateLimiter (Anfragebudgets pro Schlüssel): Cloudflare Rate Limiting (im Harness), Redis (im Harness). Payments (Checkout und Abrechnung): Polar (geplant), Stripe (im Harness). TextModel (eine Modellantwort): Anthropic (im Harness), OpenAI-compatible (im Harness). Push (Benachrichtigungen an Geräte): APNs (im Harness), FCM (im Harness), Web Push (im Harness). Signer (Signieren per Schlüsselreferenz): Turnkey (im Harness).

DESIGNREGELN

Vier Regeln, die das Design einhält.

  • 01

    Module sehen nur Ports.

    Ein Modul verlangt eine Datenbank, einen Mailer, ein Captcha. Es berührt nie ein Cloudflare-Binding oder einen Anbieter-Client. Adapter antworten. Diese eine Regel macht den späteren Wechsel weg von Cloudflare zur Änderung eines einzigen Crates.

    ModulMailerAdapter

  • 02

    Die Komposition geschieht zur Compile-Zeit.

    Kein Plugin-Laden, kein Registry-Dienst, keine Überraschungen zur Laufzeit. Der Worker enthält, was die Venture aufgelistet hat, und der Compiler ist der erste Reviewer. Ein Modul, dessen Quellcode nicht in den gemeinsamen Build gelangen soll, kann als eigener Worker laufen, über ein Service Binding unter demselben Pfad eingebunden. Es ist weiterhin zusammengestellt, nur nicht in dieselbe Binärdatei.

    kompilierenablehnendeployen

  • 03

    Ein Venture, eine Datenbank.

    Zur Laufzeit wird zwischen Unternehmen nichts geteilt. Jedes hat seinen eigenen Worker, seine eigenen Daten, seine eigenen Secrets. Ein Venture lässt sich sichern, verschieben oder abschalten, ohne ein anderes zu berühren.

    WorkerDatenbankGeheimnisse
    WorkerDatenbankGeheimnisse
    WorkerDatenbankGeheimnisse

    keine gemeinsame Runtime

  • 04

    Zustandslos von Grund auf.

    Nichts überdauert eine Anfrage außer dem, was in die Datenbank geschrieben wird. Bestätigungs- und Abmeldelinks sind signierte Tokens, sodass kein Session-Speicher betrieben, skaliert oder geleakt werden muss.

    AnfrageWorkerDatenbank

    kein Session-Speicher

STATUS

Wo der Harness steht.

Der Fortschritt wird offen als Issues und Meilensteine verfolgt.

  1. M0erledigt

    Fundament

    Workspace-Tooling, Core, die Cloudflare-Runtime, die Adapter für Resend und Turnstile, der SQLite-Adapter, die fz-CLI und das Test-Kit.

  2. M1erledigt

    Erste Module

    E-Mail-Anmeldung, Warteliste, Templates, die Sicherheits-Baseline und Observability.

  3. M2in Arbeit

    Erste Venture live

    Veröffentlichung auf crates.io, Dokumentation, Versionierung der Verträge und die erste Venture auf ihrer eigenen API-Domain.

  4. M3erledigt

    Portabilität für Self-Hosting

    Der Postgres-Adapter, die native Runtime, eine Paritäts-Suite auf SQLite und Postgres sowie Datenexport und -import.

DESIGN
30 Entscheidungsprotokolle, alle im Repository
ARCHITEKTUR
12 Abschnitte im Architekturdokument
ERSTE MODULE
E-Mail-Anmeldung und Warteliste, gebaut
VERÖFFENTLICHT
Die meisten Crates sind auf crates.io. Eine Release-Runde steht noch aus.
MANAGED SERVICE
Noch nicht gebaut. Die Control Plane ist entworfen, nicht geschrieben.

Harness-Zahlen: gelesen aus Cratefield/harness am 2026-10-21.

MEILENSTEINE →

SICHERHEIT UND DATENSCHUTZ

Sechs Ebenen zwischen einer Anfrage und den Daten.

Jede Ebene ist eine Kontrolle, die der Harness dokumentiert. Die vollständige Liste steht in seinen Sicherheits- und Datenschutzdokumenten.

  1. 01 · EDGE

    Nur die eigenen Origins der Venture

    Der Worker der Venture antwortet auf ihrer eigenen Domain. CORS erlaubt nur die Origins, die die Venture auflistet, und jede Antwort gibt eine Request-ID zurück.

  2. 02 · MISSBRAUCH

    Bots und Floods

    Turnstile, im Zweifel ablehnend. Rate Limits auf jedem öffentlichen Schreibzugriff, über den RateLimiter-Port.

  3. 03 · ANFRAGEN

    Fehler und Logs ohne Adressen

    Fehler sind problem+json mit einem festen Slug je Fall. Eine strukturierte Zeile pro Anfrage, niemals eine E-Mail-Adresse.

  4. 04 · TOKENS

    Links statt Sessions

    Bestätigungs- und Abmelde-Links sind HMAC-signiert, mit Schlüsselrotation. Es gibt keinen Session-Speicher, den man betreiben, skalieren oder dessen Daten abfließen könnten.

  5. 05 · GEHEIMNISSE

    Envelope-Verschlüsselung

    Geheimnisse sind per Envelope-Verschlüsselung geschützt und an ihre Zeile gebunden. Der Local-File-Provider des KMS-Ports verweigert den Produktivbetrieb.

  6. 06 · ISOLIERUNG

    Eine Venture, eine Datenbank

    Keine Runtime wird zwischen Unternehmen geteilt. Jedes hat seinen eigenen Worker, eigene Daten und Geheimnisse und kann einzeln verschoben oder abgeschaltet werden.

SECURITY.md →   PRIVACY.md →

WAS OFFEN IST

Die Fabrikhalle ist öffentlich. Die Rezepte nicht.

Der Harness, seine Runtime, seine Adapter und die ersten beiden Module stehen unter der MIT-Lizenz und werden offen entwickelt. Jeder kann darauf ein Backend bauen, und jede Venture, die wir betreiben, tut das. Die Module, die abbilden, wie Factory Zero seine Unternehmen betreibt, bleiben privat. Auch das Backend jeder Venture ist privat.

Ein Venture ist das Harness selbst. Cratefield nimmt das Open-Source-Harness und fügt die verwaltete Schicht darum hinzu: Es würde den Worker, die Datenbank und die Secrets in Ihrem eigenen Cloudflare-Konto bereitstellen und anschließend betreiben. Das Harness ist real und läuft; diese Control Plane ist entworfen und noch nicht geschrieben. Hier verdient die Modulgrenze auch ihren Platz: Ein Kunde kann ein eigenes Modul bauen und deployen, ohne dass der Quellcode je zu uns gelangt.

Entscheidungen werden festgehalten, während sie fallen. Das Architekturdokument und die Entscheidungsdokumente liegen im Repository, einschließlich desjenigen, das festhält, warum ein erster Versuch verworfen wurde.

Lizenzen im gesamten Stack

Von den 17 Ventures im Stack sind 11 Open Source, jedes mit einem öffentlichen Repository unter einer OSI-Lizenz. Die Leiste und die Kacheln werden aus dem Lizenzfeld des Registers gespeist.

  • KontinuumMIT
  • CratefieldMIT
  • ColonizerMIT
  • SupportGeniusMIT
  • promptdecodeMIT
  • Keep ShippingMIT
  • LedgersMIT
  • Ghostwritin'MIT
  • SealbinApache-2.0
  • Living BrainApache-2.0
  • TokkerApache-2.0
  • VibeCaddieNicht Open Source
  • PosPluginNicht Open Source
  • OwlpostNicht Open Source
  • release.showNicht Open Source
  • ShoalNicht Open Source
  • SqueezinNicht Open Source

Stack-Ventures nach Lizenz: Kontinuum: MIT. Cratefield: MIT. VibeCaddie: Nicht Open Source. Colonizer: MIT. SupportGenius: MIT. promptdecode: MIT. PosPlugin: Nicht Open Source. Keep Shipping: MIT. Owlpost: Nicht Open Source. Sealbin: Apache-2.0. release.show: Nicht Open Source. Living Brain: Apache-2.0. Shoal: Nicht Open Source. Tokker: Apache-2.0. Ledgers: MIT. Ghostwritin': MIT. Squeezin: Nicht Open Source.