/platform/ · The product, in two halves
We run it. You own it.
Cratefield comes in two halves. One of them is finished: the pieces are written, published and open source, and you can build them into a backend on your own machine and run it wherever you like, today, without us. The other half is the running of it — putting it together, building it, creating its database, applying updates in order, holding the secrets, attaching your domain and sending the logs back. That half is Planned and not built, so everything below the next section is a description of the design rather than a product you can buy.
Today, without us Shipping
What you can build right now.
You add the pieces you want to a project, build it once, and deploy it. All of it is MIT licensed and published on crates.io, which means it keeps working whether or not the service on the rest of this page ever exists.
01
The pieces are already written Shipping
Sign-ups, a waitlist and content, each arriving with its own forms and admin pages, beside notifications, webhooks, telemetry and more — 17 published modules in all. Sign-in with passkeys or Google is its own open-source service beside them. Take the ones you need and leave the rest out. What each one does.
02
They become one thing Shipping
The pieces compile into a single backend on your own machine. Wire two of them together wrong and it is caught when the thing is built, not when a customer hits it.
03
It runs where you put it Shipping
Cloudflare Workers with a database of its own, or one Linux binary on your own Postgres, with a Dockerfile in the repository if that is how you deploy. fz data export writes everything back out in one command.
Free, and free of us: you pay your cloud provider directly and nothing to Cratefield. What running it yourself involves, and the source.
The service Planned
What we would take off your hands.
The licence is MIT and stays MIT. A fee would buy the running of it: the parts of owning a backend that nobody enjoys owning and everybody ends up owning anyway.
The intended launch price is $19 per backend per month, flat. The arithmetic behind it is on the pricing page. There is nothing to buy yet.
- Assembling your backend from the pieces you picked
- Deploying every change, and compiling only when the module set is new, with a build log you can read
- Creating the database and applying its updates, in order
- Holding secrets, rotating signing keys, keeping both out of the logs
- Attaching your domain and renewing its certificate
- Forwarding the request logs back to you
- Rolling forward when a piece of it ships a new version
The account boundary
Where each thing lives.
Your infrastructure account
Billed to you by the provider, directly. Keeps running if you take the key back.
Our control planePLANNED
No application data. No user records. No database contents.
Two modes
Your account, or your domain on ours.
Two of them, on purpose, because two different people ask for this. If you want your own cloud account, your own bill from it and a key you can take back at any moment, that is the first. If you would rather never open a cloud console in your life, point your domain at us and that is the second. Both are Planned; neither is built. They differ in who holds the infrastructure, not in what your backend is.
| Aspect | Your account | Your domain on ours |
|---|---|---|
| What you set up | A limited key you create, and can delete | A CNAME at your existing registrar, pointing at us |
| Where the Worker and database live | Your account | Ours, with a database of its own |
| Who the provider bills | You, directly. Nobody marks it up | Us. It is inside our fee |
| Your TLS certificate | Your domain'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 anyone else |
| 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 | Delete the key. The backend, its database and its domain keep running | We hand back the database. The hostname is yours; repoint it |
| What a custom domain costs 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 key to hold, no bill from a third party. It also gives up the argument the first mode is built on, so this site will not pretend the two are the same thing. The boundary is identical in both: one database per backend either way.
Deploy pipeline
Changing the pieces is a deploy.
Your backend is put together once and then run, so adding or removing a piece means a new deploy rather than a switch in a dashboard. It would usually not mean a new compile: what gets built depends only on which pieces you picked, so a combination somebody has already built could be uploaded instead of built again — Designed, in issue #59. When it does compile, you get a log you can read. Why it works that way.
- 01Connect your account with a key you controlyou
- 02Pick the pieces you needyou
- 03Assemble your backend from themus
- 04Build it, with a log you can readus
- 05Create its database, apply the updatesyour account
- 06Put the secrets where only your backend can read themyour account
- 07Deploy the Worker, attach api.yourdomainyour account
- 08The logs stream back to youyou
Your own code Designed
A piece we never see.
Some of what your product does is the part you would not hand to a supplier. That part can sit beside the rest as a piece you write and deploy yourself, plugged into your backend at its own address. It reads and writes the same database as everything else, so it is a real part of the backend rather than a webhook bolted on the side, and it runs on the same machine as the rest, with no trip across the network in between.
Three things follow from that. Your code never goes into our build, so we cannot read it and somebody else’s change cannot break it. It ships when you ship, not when we do. And it would be given secrets of its own rather than the backend’s: something we did not write should not be handed the key that signs everything else. That last part is still unbuilt.
The plug itself is merged in the open-source core, so you can use it today. What is unbuilt is everything the managed service would add around it, which is the rest of this page. The epic and its remaining issues are public, and the mechanics are on the technology pages.
The key you would hand us Planned
Exactly what it can do, and nothing else.
If you take the first mode and connect your own Cloudflare account, this is the key we would ask for. You create it in your own dashboard, limited to one account and one domain, and you can delete it there at any moment. These are Cloudflare’s own permission names, written down for a system that is not running yet, so check them against the current list before you issue anything.
| Permission | Level | Used for | Without it |
|---|---|---|---|
| Workers Scripts | Account · Edit | Upload the built backend and set its secrets | No deploys |
| D1 | Account · Edit | Create the database and apply its updates | No database, no updates |
| Workers KV Storage | Account · Edit | The storage rate limiting and caching bind to | Rate limiting falls back to one machine's own memory |
| Workers Routes | Zone · Edit | Attach api.yourdomain to the backend | Deploy to a workers.dev subdomain only |
| DNS | Zone · Edit | Create the api. record | You create the record by hand |
| Account Settings | Account · Read | Read the account id and check the plan the database limits depend on | You type the account id in yourself |
Revocation
If you take the key back.
There is no offboarding process, because there is nothing to hand back. Your backend, its database and its domain are already in your account and they keep running. The one file that describes what it is made of is yours too; keep it in 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 forwarding
- Our invoice
Join the waitlist
Request early access.
What happens next: you get a confirmation link by email — click it to lock in your spot. Then one more email when the service can actually create a backend in an account, with what it needs from you and a date. Nothing else, and your address is not shared. This form runs on Cratefield's own waitlist piece, at api.cratefield.com, which is one of the pieces you can use yourself.
You do not need to sign up to read or build anything. The source is public and it is the half that already works.
Check your inbox
We sent a confirmation link to . Click it to hold your place on the Cratefield waitlist.
It can take a minute — check Spam or Promotions if it isn’t there. Already confirmed before? Then you’re already on the list; nothing more to do.