Every container gets its own kernel.
Push the docker-compose.yml you already have. CargoForge runs it exactly as written — we just give each container a real guest kernel of its own instead of a slot in one shared between everyone else on the box.
Deployment
- Build
- Push
- Sealing container…
ds-7f2e1a-web
Healthy · 3 services
- Shared with
- nobody
The manifest
Five layers between your laptop and your running container.
This is the whole stack, in order. We're not going to pretend there's nothing between the fleet we run and the compose file you wrote — here it is.
Fleet
Real physical hosts behind one control plane. You never see the hardware, and you never have to.
Physical host
Real hardware under every container — no nested virtualization tax, no noisy neighbors.
Worker agent
Runs directly on the host and calls out to the control plane. It never listens for an inbound connection — not from the internet, not from us.
Sealed container
Every container it starts gets its own real guest kernel in a lightweight virtual machine. Not a namespace. Not a chroot. Its own kernel.
Your compose file
The exact docker-compose.yml already in your repo. We don't invent a format.
What's actually different
The short, unglamorous list of reasons.
Your compose file, unmodified
No proprietary schema, no translation step, no migration guide. The file already in your repo is the deploy.
A kernel per container, not a namespace
Kata Containers, not cgroups pretending to be a boundary. A breakout has nowhere to climb to — the kernel it escaped into is the only one it ever had.
Agents that only ever call out
Every worker dials the control plane. None of them accept an inbound connection — not from the internet, not from us. There's no standing SSH key to lose.
One ceiling, not one per project
Container and project limits are enforced across the whole account, so splitting one big project into five small ones doesn't quietly buy you more room.
The fleet, on one screen
Every host and worker's health in the Crane console — not something you find out by SSHing into a box at 2am.
A dead host isn't your incident
If the machine your project runs on fails, it's rescheduled onto a healthy one automatically. Same volumes, same hostname, nothing for you to file.
The tariff
What a dyno used to cost.
Heroku called it a dyno — a slice of a shared process. We call it a container, because it isn't a slice of anything: it's sealed with its own guest kernel in a real virtual machine, billed the way a shipping line bills a container — by what you actually put on the vessel.
One project, for finding out if this is for you — or for the side project that doesn't need to run at 3am.
- 10 containers
- 1 project
- 100 hrs/mo awake — idles when quiet, wakes on the next request
Where most teams land
For the projects that pay their own way.
- 50 containers account-wide
- 20 projects
- Admin console access
- Per-service ingress
Bring your own bare metal. We just run the containers.
- Unlimited projects and hosts
- Your own hardware fleet
- Dedicated ingress + support
- Custom account quotas
Cast off in one push
The whole deploy, in one session.
We're not going to make up a containers served number to look bigger than we are — CargoForge is new.
What's real: every container up there got its own guest kernel, the agent that ran it has never once accepted an inbound connection, and that terminal is the actual job queue, not something we animated for this page.
Cast off.
Point CargoForge at the compose file you already have. We'll take it from there.