FACTORY ZERO

TECHNOLOGIE / OPEN SOURCE

Des pièces ordinaires. Assemblées une fois.

Chaque venture a besoin d’un backend, et aucune ne devrait en construire un. Les éléments dont une entreprise a besoin pour exister sont écrits une seule fois, sous forme de harness open source en Rust. Une venture choisit les modules voulus, les assemble dans un seul fichier et se déploie comme un worker sans état unique, avec sa propre base de données.

GITHUB.COM/CRATEFIELD/HARNESS →

La factory en chiffres

ventures
2317 validation · 1 prototype · 5 lancement
sur la stack
17sur 23 ventures, les parties partagées
open source
118 MIT · 3 Apache-2.0
exécutées sur le harness
1818 en ligne aujourd’hui · 1 prévu
décisions d’architecture
30dans le dépôt du harness

COMMENT UNE VENTURE EST CONSTRUITE

Un fichier nomme l’entreprise.

Le backend d’une venture est un petit projet Rust. Il liste les modules qu’il utilise, les adapters qui les relient au monde extérieur, ainsi que le nom et le domaine propres à la venture. Tout le reste est le harness. Une fois compilé, le résultat est un seul worker qui contient exactement ces modules, et rien d’autre.

Si un module a besoin de quelque chose que le runtime ne peut pas fournir, ou si deux modules revendiquent la même table, la compilation échoue avant tout déploiement. Une venture mal configurée ne peut pas atteindre la 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. Étape 1

    Nommez-la

    La venture, son domaine, ses modules et les adapters qui y répondent. Un seul fichier.

  2. Étape 2

    Composez-la

    La compilation refuse un module dont le runtime ne fournit pas le port, ainsi que deux modules qui revendiquent la même table ou la même route.

  3. Étape 3

    Livrez-la

    Un worker sans état contenant exactement les modules listés, avec sa propre base de données, ses secrets et son domaine.

LES COUCHES

Six couches, du runtime jusqu’aux produits.

À lire de bas en haut : où le code s’exécute, le harness dont chaque backend est compilé, les backends, les produits partagés, les agents qui font tourner la société, puis les ventures autonomes. Les pastilles pleines sont en ligne aujourd’hui, les pastilles à contour sont dans le harness, les pastilles en pointillé sont prévues.

01RUNTIME

Cloudflare Workers, compilés en WebAssembly

Là où s’exécute chaque worker de venture. Les données et l’e-mail se trouvent à côté, et le même code peut tourner sur un serveur.

Workers (wasm32)Base de données D1E-mail ResendKVTurnstileLimitation de débitPostgres, runtime natif
02HARNESS

Cratefield : le cœur Rust open source

Les ports, le routeur et les modules. Un module demande un port ; un adapter répond.

Cratefield

Ports

DatabaseMailerCaptchaRateLimiterKeyValueSigner

Modules

email-signupliste d’attente
03BACKENDS

Un worker et une base de données par venture

Chaque venture est composée à partir du harness et déployée séparément. En ligne sur le harness aujourd’hui :

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

La stack : les produits auxquels chaque venture se branche

Les produits partagés, rangés selon ce qu’ils font. Chacun est une société avec ses propres clients.

Livrer et exploiter

  • VibeCaddie
  • Keep Shipping
  • release.show
  • Shoal

Communication

  • Owlpost
  • Squeezin

Sécurité

  • promptdecode
  • Sealbin

Clients

  • SupportGenius
  • PosPlugin
  • Ledgers

Contenu et IA

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

Cinq couches, un agent pour chaque fonction

Chaque fonction de chaque couche est un agent. Colonizer exécute les agents de code de la couche de construction.

  • DÉCOUVRIR3 agents
  • CONSTRUIRE4 agents
  • EXPLOITER4 agents
  • DISTRIBUER3 agents
  • APPRENDRE3 agents

Colonizer : des agents de code qui transforment les issues GitHub en pull requests

06PRODUITS

Les ventures autonomes

Les ventures hors de la stack. Elles héritent de la fondation et ne l’enrichissent pas.

Undercover RockstarsYogininiFindsYou.workGroove GuruBloodrankratecla.im

Les six couches, de bas en haut

  1. runtime : Cloudflare Workers, compilés en WebAssembly. Là où s’exécute chaque worker de venture. Les données et l’e-mail se trouvent à côté, et le même code peut tourner sur un serveur.
  2. harness : Cratefield : le cœur Rust open source. Les ports, le routeur et les modules. Un module demande un port ; un adapter répond.
  3. backends : Un worker et une base de données par venture. Chaque venture est composée à partir du harness et déployée séparément. En ligne sur le harness aujourd’hui :
  4. rayons : La stack : les produits auxquels chaque venture se branche. Les produits partagés, rangés selon ce qu’ils font. Chacun est une société avec ses propres clients.
  5. agents : Cinq couches, un agent pour chaque fonction. Chaque fonction de chaque couche est un agent. Colonizer exécute les agents de code de la couche de construction.
  6. produits : Les ventures autonomes. Les ventures hors de la stack. Elles héritent de la fondation et ne l’enrichissent pas.

UNE REQUÊTE, DE BOUT EN BOUT

Qui fait quoi lorsqu’un visiteur s’inscrit.

Tracé uniquement à partir des liens du registre. Un trait plein est en ligne aujourd’hui et porte du trafic ; un trait pointillé est prévu et n’en porte pas encore.

  1. Visiteur

    une personne sur le site d’une venture

  2. Worker de la venture

    un worker par venture, sur le harness Cratefield

    en ligne

  3. Owlpost

    e-mail pour les ventures

    en ligne

  4. SupportGenius

    signalements de bugs et support

    prévu

  5. Colonizer

    agents de code, sur le harness

    en ligne

  6. Living Brain

    une connaissance qui retient ce qui a fonctionné

    prévu

Les liens de ce flux : Visiteur vers worker de venture, requête HTTPS : en direct. Worker de venture vers Owlpost, e-mail de confirmation : en direct. Worker de venture vers SupportGenius, les erreurs deviennent des issues : prévu. SupportGenius vers Living Brain, le support alimente la base de connaissances : prévu. Colonizer vers Living Brain, les agents alimentent la base de connaissances : en direct.

S’inscrire sur une venture, et où va le message ensuite. Les flèches indiquent le sens de chaque lien ; le statut est celui du registre.

LES MODULES NE VOIENT QUE DES PORTS

Les ports d’un côté. Les adapters de l’autre.

Un module demande un port, jamais un fournisseur. Le runtime répond par un adapter. Les adapters appartiennent au harness ; le statut indique où une venture en ligne en utilise un aujourd’hui.

  • Database

    tables, requêtes et migrations

    • D1 (en ligne)
    • Postgres (dans le harness)
    • SQLite (dans le harness)

  • Mailer

    e-mail transactionnel

    • Resend (en ligne)
    • Owlpost (prévu)

  • Captcha

    une vérification anti-bot, qui refuse en cas d’échec

    • Turnstile (dans le harness)

  • KeyValue

    petit état clé-valeur

    • Cloudflare KV (dans le harness)

  • RateLimiter

    quotas de requêtes par clé

    • Cloudflare Rate Limiting (dans le harness)
    • Redis (dans le harness)

  • Payments

    paiement et facturation

    • Polar (prévu)
    • Stripe (dans le harness)

  • TextModel

    une complétion de modèle

    • Anthropic (dans le harness)
    • OpenAI-compatible (dans le harness)

  • Push

    notifications vers les appareils

    • APNs (dans le harness)
    • FCM (dans le harness)
    • Web Push (dans le harness)

  • Signer

    signature par référence de clé

    • Turnkey (dans le harness)

Ports et leurs adapters : Database (tables, requêtes et migrations) : D1 (en ligne), Postgres (dans le harness), SQLite (dans le harness). Mailer (e-mail transactionnel) : Resend (en ligne), Owlpost (prévu). Captcha (une vérification anti-bot, qui refuse en cas d’échec) : Turnstile (dans le harness). KeyValue (petit état clé-valeur) : Cloudflare KV (dans le harness). RateLimiter (quotas de requêtes par clé) : Cloudflare Rate Limiting (dans le harness), Redis (dans le harness). Payments (paiement et facturation) : Polar (prévu), Stripe (dans le harness). TextModel (une complétion de modèle) : Anthropic (dans le harness), compatible OpenAI (dans le harness). Push (notifications vers les appareils) : APNs (dans le harness), FCM (dans le harness), Web Push (dans le harness). Signer (signature par référence de clé) : Turnkey (dans le harness).

RÈGLES DE CONCEPTION

Quatre règles que la conception respecte.

  • 01

    Les modules ne voient que des ports.

    Un module demande une base de données, un service d’envoi d’e-mails, un captcha. Il ne touche jamais un binding Cloudflare ni un client fournisseur. Ce sont les adaptateurs qui répondent. Cette seule règle fait qu’un futur départ de Cloudflare revient à changer une seule crate.

    moduleMaileradapter

  • 02

    La composition se fait à la compilation.

    Pas de chargement de plugins, pas de service de registre, pas de surprises à l’exécution. Le worker contient ce que la venture a listé, et le compilateur est le premier relecteur. Un module dont le code source ne doit pas entrer dans la compilation commune peut tourner comme son propre worker, monté sur le même chemin via un service binding. Il est toujours composé, simplement pas dans le même binaire.

    compilerrefuserdéployer

  • 03

    Une venture, une base de données.

    Rien n’est partagé à l’exécution entre les entreprises. Chacune a son propre worker, ses propres données, ses propres secrets. Une venture peut être sauvegardée, déplacée ou arrêtée sans toucher une autre.

    workerbase de donnéessecrets
    workerbase de donnéessecrets
    workerbase de donnéessecrets

    aucun runtime partagé

  • 04

    Sans état par construction.

    Rien ne survit à une requête, sauf ce qui est écrit dans la base de données. Les liens de confirmation et de désabonnement sont des jetons signés : il n’y a donc aucun magasin de sessions à exploiter, à dimensionner ou à faire fuir.

    requêteworkerbase de données

    aucun magasin de sessions

STATUT

Où en est le harness.

L’avancement est suivi en toute transparence, sous forme d’issues et de jalons.

  1. M0terminé

    Fondation

    L’outillage du workspace, le cœur, le runtime Cloudflare, les adapters Resend et Turnstile, l’adapter SQLite, la CLI fz et le kit de test.

  2. M1terminé

    Premiers modules

    Inscription par e-mail, liste d’attente, modèles, socle de sécurité et observabilité.

  3. M2en cours

    Première venture en ligne

    Publication sur crates.io, documentation, versionnement des contrats et première venture sur son propre domaine d’API.

  4. M3terminé

    Portabilité en auto-hébergement

    L’adapter Postgres, le runtime natif, une suite de parité sur SQLite et Postgres, ainsi que l’export et l’import de données.

DESIGN
30 décisions d’architecture, toutes dans le dépôt
ARCHITECTURE
12 sections dans le document d’architecture
PREMIERS MODULES
Inscription par e-mail et liste d’attente, réalisées
PUBLIÉ
La plupart des crates sont sur crates.io. Une série de publications est en attente.
SERVICE GÉRÉ
Pas encore construit. Le plan de contrôle est conçu, pas écrit.

Chiffres du harness : relevés dans Cratefield/harness le 2026-10-21.

JALONS →

SÉCURITÉ ET CONFIDENTIALITÉ

Six couches entre une requête et les données.

Chaque couche est un contrôle documenté par le harness. La liste complète figure dans ses documents de sécurité et de confidentialité.

  1. 01 · EDGE

    Uniquement les origines propres à la venture

    Le Worker de la venture répond sur son propre domaine. CORS n’autorise que les origines listées par la venture, et chaque réponse renvoie un identifiant de requête.

  2. 02 · ABUS

    Bots et afflux massifs

    Turnstile, qui refuse en cas d’échec. Des limites de débit sur chaque écriture publique, via le port RateLimiter.

  3. 03 · REQUÊTES

    Erreurs et journaux sans adresses

    Les erreurs sont en problem+json, avec un slug fixe pour chaque cas. Une ligne structurée par requête, jamais d’adresse e-mail.

  4. 04 · JETONS

    Des liens, pas des sessions

    Les liens de confirmation et de désinscription sont signés par HMAC, avec rotation des clés. Aucun magasin de sessions à exploiter, à dimensionner ou à voir fuiter.

  5. 05 · SECRETS

    Chiffrement par enveloppe

    Les secrets sont chiffrés par enveloppe et liés à leur ligne. Le fournisseur de fichier local du port KMS refuse la production.

  6. 06 · ISOLEMENT

    Une venture, une base de données

    Aucun runtime n’est partagé entre les sociétés. Chacune a son propre worker, ses données et ses secrets, et peut être déplacée ou arrêtée seule.

SECURITY.md →   PRIVACY.md →

CE QUI EST OUVERT

L’atelier de l’usine est public. Les recettes ne le sont pas.

Le harness, son runtime, ses adapters et les deux premiers modules sont sous licence MIT et développés en open source. Chacun peut construire un backend dessus, et chaque venture que nous exploitons le fait. Les modules qui codifient la façon dont Factory Zero exploite ses sociétés restent privés. Le backend propre à chaque venture est privé lui aussi.

Une venture est le harness lui-même. Cratefield reprend le harness open source et y ajoute la couche gérée : il provisionnerait le worker, la base de données et les secrets dans votre propre compte Cloudflare, puis les exploiterait. Le harness est réel et fonctionne ; ce plan de contrôle est conçu et pas encore écrit. C’est aussi là que la frontière des modules prend tout son sens : un client peut construire et déployer un module à lui sans que le code source n’arrive jamais jusqu’à nous.

Les décisions sont consignées au moment où elles sont prises. Le document d’architecture et les décisions consignées sont dans le dépôt, y compris celle qui explique pourquoi une première tentative a été abandonnée.

Licences à travers la stack

Sur les 17 ventures de la stack, 11 sont open source, chacune avec un dépôt public sous licence OSI. La barre et les tuiles sont tracées à partir du champ licence du registre.

  • KontinuumMIT
  • CratefieldMIT
  • ColonizerMIT
  • SupportGeniusMIT
  • promptdecodeMIT
  • Keep ShippingMIT
  • LedgersMIT
  • Ghostwritin'MIT
  • SealbinApache-2.0
  • Living BrainApache-2.0
  • TokkerApache-2.0
  • VibeCaddieNon open source
  • PosPluginNon open source
  • OwlpostNon open source
  • release.showNon open source
  • ShoalNon open source
  • SqueezinNon open source

Ventures de la stack par licence : Kontinuum : MIT. Cratefield : MIT. VibeCaddie : Non open source. Colonizer : MIT. SupportGenius : MIT. promptdecode : MIT. PosPlugin : Non open source. Keep Shipping : Apache-2.0. Owlpost : Non open source. Sealbin : Apache-2.0. release.show : Non open source. Living Brain : Apache-2.0. Shoal : Non open source. Tokker : Apache-2.0. Ledgers : MIT. Ghostwritin' : MIT. Squeezin : Non open source.