/platform/ · The managed service Planned
We run it. You own it.
Cratefield would run your backend: generating the manifest, building it, applying migrations, holding secrets, attaching your domain, renewing its certificate and streaming the logs back. That is the service, and it is what a fee would buy. None of it is built yet, so this page describes the design rather than a product, and it describes both of the ways the infrastructure could be held.
The service
What we would operate.
The licence is MIT and stays MIT. A fee would buy the operating: the parts of running a backend that no team enjoys owning and every team ends up owning anyway.
The intended launch price is $19 per backend per month, flat. The arithmetic behind it is on the pricing page. It is not purchasable yet.
- Generating the Cargo manifest and the composition file from the modules you pick
- Building Rust to wasm on every change, with a build log you can read
- Creating the database and applying forward-only migrations, in order
- Holding secrets, rotating signing keys, keeping both out of the logs
- Attaching your domain and renewing its certificate
- Forwarding request spans and logs back to you
- Rolling forward when a module ships a new contract version
The account boundary
Where each thing lives.
Your infrastructure account
Billed to you by the provider, directly. Keeps running if the token is revoked.
Our control planePLANNED
No application data. No user records. No database contents.
Two modes
Your account, or your domain on ours.
Two modes, offered on purpose, because two different buyers ask for this. A technical founder usually wants the first: their own infrastructure account, their own bill, a token they can revoke. Someone running a business rather than a platform usually wants the second: point a CNAME at us from whatever registrar they already have, and never see a cloud console. Both are Planned; neither is built. They differ in who holds the infrastructure, not in what the backend is.
| Aspect | Your account | Your domain on ours |
|---|---|---|
| What you set up | A scoped API token you issue and can revoke | A CNAME at your existing registrar, pointing at us |
| Where the Worker and database live | Your account | Ours, isolated per tenant |
| Who the provider bills | You, directly. Nobody marks it up | Us. It is inside our fee |
| Your TLS certificate | Your zone's own certificate | Issued and renewed for your hostname, automatically |
| Access to our configuration | Not applicable. It is your account | None. You cannot reach our security, caching or routing rules, and cannot affect another tenant |
| If you change your DNS | You are changing your own zone | Your hostname stops resolving to us. Nothing on our side breaks |
| If you leave | Revoke the token. The Worker, database and domain keep running | We hand back the database. The hostname is yours; repoint it |
| Custom hostname cost to us | None | 100 hostnames included, then $0.10 per hostname per month, to a limit of 50,000 |
developers.cloudflare.com/
The second mode is what Supabase does, and it is a real convenience: no cloud account, no token, no bill from a third party. It also gives up the argument the first mode is built on, so this site does not pretend the two are equivalent. The isolation boundary is the same in both: one database per tenant either way.
Token scopes
What the token would need, and why.
Proposed scopes for the Planned control plane. You create the token in your provider dashboard, scoped to one account and one zone, and you can delete it there at any time. These are Cloudflare permission names; re-check them against the current list before issuing.
| Permission | Level | Used for | Without it |
|---|---|---|---|
| Workers Scripts | Account · Edit | Upload the compiled Worker and set Worker secrets | No deploys |
| D1 | Account · Edit | Create the tenant database and apply forward-only migrations | No database, no migrations |
| Workers KV Storage | Account · Edit | Rate-limit and cache namespaces the runtime binds to | Rate limiting falls back to in-memory per isolate |
| Workers Routes | Zone · Edit | Attach api.yourdomain to the Worker | Deploy to a workers.dev subdomain only |
| DNS | Zone · Edit | Create the api. record | You create the record by hand |
| Account Settings | Account · Read | Resolve the account id and confirm the Workers Paid plan for D1 limits | Manual account id entry |
Deploy pipeline
Changing modules is a deploy.
Compile-time composition means changing modules is a deploy, not a config flip, and we won't draw one. It usually is not a compile: the artifact is a function of the module set, not of you, so a set someone has already built is uploaded rather than rebuilt. When it does compile you get a build log you can read.
- 01Connect your account with a scoped tokenyou
- 02Pick modulesyou
- 03Generate Cargo.toml and harness.rsus
- 04Build Rust to wasm32 in CIus
- 05Create the D1 database, apply migrationsyour account
- 06Set secrets as Worker secretsyour account
- 07Deploy the Worker, attach api.yourdomainyour account
- 08Logs and request spans stream back to youyou
Your own modules Designed
A module we never see.
Some modules encode something you will not hand to a supplier. Those run as a sidecar: a worker of its own, carrying one module, built and deployed by you, mounted into your backend at /v1/<name> over a service binding. Both workers sit in your account, so you deploy it with your own credentials. It binds the same database as the rest, so it is a real module with real ports rather than a webhook, and the platform runs both workers on the same thread of the same server, so the seam costs no measurable latency.
Three consequences worth stating. Your module never enters our build, so it cannot be read by us and cannot be broken by a change to somebody else’s. It ships on your release cycle, not ours. And it is provisioned its own secrets rather than the backend’s: a module we did not build is not handed the key that signs everything else.
Designed and unbuilt, like the rest of this page. The epic and its nine issues are public.
Revocation
If you delete the token.
There is no offboarding process because there is nothing to hand back. The composition file and Cargo manifest are yours to check into your own repository.
Keeps running
- The Worker
- The D1 database
- Worker secrets
- api.yourdomain
- Every module you deployed
Stops
- Managed rebuilds and deploys
- Managed migrations
- Log and span forwarding
- Our invoice
Early access
Request early access.
What happens next: we store the address and your note. When the control plane can provision into an account, we write to you once with the token scopes and a date. We do not send anything else, and the address is not shared.
You do not need to sign up to read anything. The source is public.