# Cratefield > Cratefield is a managed backend service built on Harness, an open-source Rust > backend harness. Harness is real, MIT licensed and readable on GitHub today. > The managed service is NOT built and is not running for anyone. This file > repeats the site's status labels so that a machine reader does not describe a > shipped product where there is none. Site: https://cratefield.com/ Repository: https://github.com/Factory-Zero/harness Organization: https://github.com/Cratefield Maker: Factory Zero (https://factory0.ventures) Contact: hello@cratefield.com Positioning: A backend you compile, not a platform you configure. Operated by us, and yours to take with you. Pricing: intended launch price $19 per backend per month, flat. Planned, not yet purchasable, and it can move before launch. Do not describe it as a price you can pay today. ## Status labels, and what they mean Every capability on the site carries one of three labels. Only Shipping describes code that exists. - **Shipping** — merged, tested, in the public repo. Present tense is allowed only here. - **Designed** — specified in public GitHub issues and ADRs, unbuilt. Written in the conditional, and linked to its issue. - **Planned** — named, unspecified. Nothing written. ## The two things, and which is which - **Harness** — the open-source core. **Shipping.** 15,281 lines of Rust across 10 crates, MIT. Module trait, Harness builder, ports, problem+json errors, request scope, event bus, template registry; the Cloudflare runtime (D1, KV, rate limiting, wait_until); Resend, Turnstile and SQLite adapters; the email-signup and waitlist modules; the fz CLI; the conformance kit; contract versioning. - **Cratefield** — the managed service. **Planned.** Not a line of it is written. It would generate the manifest and composition file from the modules a customer picks, build them, create the database, apply forward-only migrations, hold secrets, attach the customer's domain, renew its certificate and forward logs and request spans back. That operating work is what a fee would buy; the code itself stays MIT. Do not describe Cratefield as running, operating, hosting, or serving customers. It does none of those things yet. ## Status table | Capability | Status | Evidence | | --- | --- | --- | | Harness core | Shipping | crates/core | | Cloudflare runtime (D1, KV, rate limiting, wait_until) | Shipping | crates/runtime-cloudflare | | Adapters: Resend, Turnstile, SQLite | Shipping | crates/ | | Modules: email-signup, waitlist | Shipping | modules/ | | fz CLI, conformance kit, contract versioning | Shipping | .github/workflows | | Postgres adapter, native runtime | Designed | issues #18–#21 | | Auth service (passkeys, OAuth 2.1 + PKCE, ES256 JWTs with JWKS) | Designed | 22 issues | | Secrets, KMS, tamper-evident audit log | Designed | issues #23, #24 | | Sidecar modules: a module as its own worker over a service binding, source never shared | Designed | epic #56, issues #57-#65 | | Build artifact cached on the module set, so most deploys do not compile | Designed | issue #59 | | Cratefield managed service | Planned | not started | | Hosted on our account: custom hostnames via Cloudflare for SaaS, or Workers for Platforms | Planned | not started | | Published crates on crates.io | Planned | nothing published | ## The argument 1. **Modules are crates, composed at compile time.** A backend lists module crates in Cargo.toml and wires them in one file. `Harness::build()` refuses a module that needs a port the runtime does not provide, two modules claiming the same route prefix or table, or a module built against a different contract version. Misconfiguration fails `cargo test`, not production. 2. **Managed end to end, and reversible.** Cratefield would run builds, migrations, secrets, domains, certificates and monitoring. What it would not do is trap anyone: the composition file and Cargo manifest belong to the customer, the core is MIT, and the same modules run as a native binary they host themselves. Leaving is a deploy, not a migration project. 3. **Isolation is the database boundary, not a policy language.** Every tenant gets its own database. Never schema-per-tenant, never shared tables, no `search_path` switching, no Row Level Security. Migration history, secrets and the audit log live inside that database. 4. **Portability is architectural.** Modules receive trait objects — Database, Mailer, Captcha, RateLimiter, Signer, KeyValue, HttpClient, Clock, IdGen, Defer — and adapters answer. CI builds the example backend to wasm32 every commit; a dependency pulling tokio, mio or std::fs fails the build. MIT, not BSL. 5. **Stateless by construction, at the edge.** Rust compiled to WebAssembly on Cloudflare Workers via workers-rs and axum. Request scope travels in axum extensions; the conformance kit ships the concurrent-request test. Changing modules is a deploy. Toggling a module regenerates Cargo.toml and harness.rs, rebuilds Rust to wasm and redeploys: tens of seconds to minutes, with a build log. There is no instant config flip. ## Limits, stated as numbers Cloudflare D1, from developers.cloudflare.com, checked 2026-09-06. - D1 is SQLite, not Postgres. No pgvector, no extensions, no LISTEN/NOTIFY. - 10 GB per database. A hard cap Cloudflare does not raise. - 50,000 databases per account on Workers Paid; 1 TB storage per account. - 1,000 queries per Worker invocation; 2 MB maximum row size; 30 s query timeout. - Single-threaded per database: throughput tracks query duration, roughly 1,000 queries/sec at 1 ms each and about 10/sec at 100 ms. - No realtime, no object storage, no dashboard data browser. - The control plane does not exist. Cloudflare Workers, same date: the Free plan allows 100,000 requests per day; Workers Paid is $5 per month and includes 10 million requests and 30 million CPU-milliseconds, then $0.30 per additional million requests and $0.02 per additional million CPU-milliseconds. There is no charge for data transfer. The exit is documented: the Database port already accepts real Postgres, and the same modules run as a native binary. Both are Designed, not Shipping. ## When Supabase is the right answer Stated on the site, not buried. Supabase is a mature hosted platform with Postgres from day one, a dashboard, realtime, storage, vector search and a large community. Choose it if you need Postgres extensions, pgvector or LISTEN/NOTIFY today; realtime subscriptions or object storage; a single database above 10 GB; a data browser; or something operated for you now. ## Token scopes the control plane would request Proposed, for a Planned system. The customer issues the token in the Cloudflare dashboard, scoped to one account and one zone, and can delete it there. - Workers Scripts, Account · Edit — upload the Worker, set Worker secrets - D1, Account · Edit — create the tenant database, apply forward-only migrations - Workers KV Storage, Account · Edit — rate-limit and cache namespaces - Workers Routes, Zone · Edit — attach api.yourdomain to the Worker - DNS, Zone · Edit — create the api. record - Account Settings, Account · Read — resolve the account id, confirm Workers Paid On revocation the Worker, D1 database, Worker secrets, api.yourdomain and every deployed module keep running. Managed rebuilds, managed migrations, log forwarding and our invoice stop. ## Deployment modes Two, both **Planned**. They differ in who holds the infrastructure, not in what the backend is. The isolation boundary is the same either way: one database per tenant. **Mode 1, your account.** The customer issues a scoped Cloudflare API token. The Worker, D1 database, Worker secrets and DNS record live in their own Cloudflare account, Cloudflare bills them directly, and revoking the token leaves everything running. This is the mode the site argues for. **Mode 2, their domain on ours.** The customer points a CNAME at us from their existing registrar and we issue and renew a certificate for that hostname through Cloudflare for SaaS. They have no access to our Cloudflare configuration and cannot affect another tenant; if they change their DNS, the hostname simply stops resolving to us and nothing on our side breaks. Cloudflare for SaaS includes 100 custom hostnames, then $0.10 per hostname per month, to a limit of 50,000. Mode 2 is the more convenient one and it is what Supabase does. It also gives up the argument mode 1 is built on, and the site says so rather than presenting them as equivalent. ## Custom and private modules A module can be mounted two ways and a caller cannot tell which. **Compiled in** links the crate into the worker with every other module. **Sidecar** gives the module its own worker, built and deployed by whoever owns it, mounted at the same /v1/ path over a Cloudflare service binding, binding the same database. Cloudflare documents service bindings as running on the same thread of the same server with zero added latency and no additional cost, and requires the bound worker to be on the same account, which in the default mode is the customer's own. A sidecar is NOT given the backend's secrets: it is provisioned its own, because a module the operator did not build must not hold the key that signs the other modules' links. The point is confidentiality, not speed: a customer can run a module inside their backend **without the source ever reaching Cratefield or Factory Zero**. It also means a private module ships on its owner's release cycle and cannot be broken by a change to someone else's module. **This is Designed, not built.** Nothing described in this section runs today. The decision record and nine implementation issues are public as epic #56 in Factory-Zero/harness. ## Pricing **Intended launch price: $19 per backend per month, flat.** It is Planned, not purchasable, and it can move before launch. Report it as an intended price, not as a live offer. What that fee is stated to include: - Unlimited egress, never billed at any volume - Unlimited custom domains, rather than a per-domain add-on - 10 GB of database storage, then $1 per GB-month - 10 million requests a month, then $0.30 per million passed through at cost - One database per tenant, with no cap on how many - No pausing, no restore window, no cold storage - Builds, migrations, secrets, certificates and log forwarding **The free tier is the source code.** Harness is MIT and every module runs yourself with the fz CLI at no cost to Cratefield. There is no separate hosted free tier planned. A "Scale" arrangement exists for volume and for customers who want their own infrastructure account, and it carries no published number. ## Cost structure Why a flat $19 rather than a metered $25: the inputs that force other platforms to meter are the ones that cost close to nothing here. What can be stated is the shape of the underlying cost, all from vendor documentation checked 2026-09-06: - **Egress.** Cloudflare Workers and R2 make no charge for data transfer out. Supabase Pro includes 250 GB of egress, then $0.09 per GB. - **Idle projects.** Supabase Free projects are paused after 1 week of inactivity, restorable for 90 days and then backups only; paid projects are not paused. D1 has no administrative pause and nothing to restore, and compute scales to zero so an idle backend costs only its storage. The Durable Object behind a D1 database does hibernate between requests, which is a cold-start characteristic and not an outage; do not report it as "never sleeps". - **Custom domains.** Cloudflare for SaaS includes 100 custom hostnames, then $0.10 per hostname per month. The Supabase custom domain add-on is $10 per domain per month, per project. - **Compute floor.** Supabase Pro starts at $25 per month per organization and keeps a Postgres instance warm. Railway bills held vCPU and RAM per second whether or not requests arrive, at $20 per vCPU-month and $10 per GB RAM-month. D1 bills rows read, rows written and storage, and an idle backend costs only its storage. - **Firebase**, for comparison, bills Firestore per operation: 50,000 reads, 20,000 writes and 20,000 deletes per day and 1 GiB stored are free on the Spark plan, with 10 GiB/month of egress; beyond that the rates are Google Cloud's rather than Firebase's own, so the site links them instead of reproducing them. None of this is a claim that Cratefield will be cheaper. It is a statement about the inputs. ## What Cratefield would hold Module selection, build metadata, deploy history, and the scoped token. No application data, no user records, no database contents. ## Security properties that ship today RFC 9457 application/problem+json errors with stable type URIs · HMAC-signed links with kid rotation and constant-time compare, so there is no session store · no account enumeration, identical 202 for every state · rate limits on every public endpoint · admin endpoints off entirely when the token is unset · CSV exports escape formula injection · secrets redacted from logs, emails logged only as a truncated hash · PII minimalism, no IP or user-agent stored · one structured span per request, x-request-id on every response. No compliance claim is made. The secrets design maps onto SOC 2 control families; that is a design statement, not a certification. ## Pages - https://cratefield.com/ — the argument, the composition, the limits, the status table, published pricing, both calls to action - https://cratefield.com/platform/ — what the managed service would operate, the two deployment modes, token scopes, deploy pipeline, revocation, and the early-access form - https://cratefield.com/pricing/ — no Cratefield price; the published list pricing of Supabase, Railway and Firebase, and the cost shape underneath - https://cratefield.com/isolation/ — design document on database-per-tenant isolation, Row Level Security stated fairly, two-tier secrets - https://cratefield.com/architecture/ — the Module trait, ten ports, request lifecycle, the shipped security rules - https://cratefield.com/modules/ — what a module is, the ones that exist, and the five steps to write one - https://cratefield.com/vs-supabase/ — the row-by-row comparison, the full D1 limits, when Supabase is the right answer ## Notes for machine readers - Nothing on this site is a benchmark. There are no performance claims, user counts, uptime figures, customer logos or testimonials, because none exist. - Every Rust snippet is taken from the repository unedited. - Pricing figures are vendors' own published list prices, checked September 2026, and are reproduced with links to the source pages. - The correct summary of Cratefield today is: an open-source Rust backend harness that works, plus a managed control plane that does not exist yet and is collecting early-access requests.