Ship a Dockerfile, keep the old one running
Point pilots at any repository with a Dockerfile and it builds a microVM image, starts it behind a health check, and cuts traffic over only once the new release answers. The previous release stays alive until then, which is what makes a rollback instant rather than a rebuild.
Any Dockerfile, and structured logs when it fails
The build turns a container image into a flat filesystem and stores it as a content-addressed template, which is what later lets machines start from it without copying it. The interesting part is the log format.
$ pilot deployuploading contextstep 3/7 RUN npm cistep 7/7 flattening to ext4health check passed, cutting overcheckout.pilotrun.appLogs an agent can act on
Build output streams as structured records rather than as a wall of text, so the thing reading it can tell which step failed and why without scraping. That matters because the intended reader is often not a person: an agent that can parse the failure can patch the Dockerfile and try again.
No Dockerfile? The agent writes one
Detection is by lockfile and project layout, and the generated file is a starting point the build loop then corrects. Django, Rails, Next.js, and anything else that boots from a command are all the same problem here.
Two ways in, one pipeline
Push a local directory from the command line, or connect a repository once and let pushes deploy themselves. The webhook is an ordinary route on every host, so there is no build service to be down.
Nothing takes traffic until it answers
Waiting a fixed number of seconds and hoping is the usual way a deploy decides it worked. Here the new release has to answer its readiness check before it receives any traffic, and the old one keeps serving until it does.
-
1
Start the new release alongside the old
Both exist at once. Nothing has moved yet.
-
2
Wait for readiness
The new machine answers its health endpoint, or it does not and the deploy stops here with the old release untouched.
-
3
Cut traffic over
The router points at the new release. The address does not change, because addresses never change.
-
4
Keep the old release
Retained, so rolling back is pointing the router back rather than building anything.
Custom domains
Point a record at the fleet and the certificate is issued on demand. Any host can answer the challenge, so issuance is not something one machine owns.
Replicas that follow load
Traffic spread across healthy replicas. A concurrency ceiling starts the next one, and excess capacity stops again, down to a floor you set.
Scale to zero, honestly
A floor of zero is the default for a real service, not a setting to find. The first request afterwards is held while the machine comes back rather than being shown a splash page, and a database is kept up for as long as a client holds a connection to it.
Promotion changes one number on a row
A prototype becomes a production service by changing one number on its row, how many copies to run, and giving it a release and a health check. Its lifecycle knobs do not move: it still suspends when idle and still wakes on demand, because a service that cannot sleep is the thing this platform exists to avoid. Nothing is rebuilt and nothing is copied, because there was never a second kind of thing to copy it into.
As a sandbox
- autoStop
- suspend
- autoStart
- true
- minRunning
- 0
- replicas
- one
After promote
- autoStop
- suspend
- autoStart
- true
- minRunning
- 0
- replicas
- one or more
The same property makes pull request previews close to free. A pull request opens, its build becomes a sandbox at its own address, and it suspends when nobody is looking at it, which is most of the time. It is destroyed when the branch merges.
Where application data actually belongs
Checkpoints capture a machine at a moment, which is the wrong granularity for a database. Volumes are the right one: durable per write, and not tied to the host that happens to be running the machine.
A machine with a volume mounted stays on its host while it holds it. When that host dies, the volume comes back wherever the machine is rescued, because the underlying storage was never local to begin with. The root disk is stored the same way, in the same bucket, with the host's NVMe as a cache in front of both. What differs is the promise. A volume write is durable when it returns, and a root write is durable at the next flush, at most 60s later. That is the difference between a place for a database and a place for everything else.
The fleet's own test battery asserts this rather than assuming it: volume data survives the host dying and the machine being rescued elsewhere.
WebJs apps have no build step, so deploying one is copying files and starting a process, and its readiness endpoint is exactly what the health gate above waits on. Neither product requires the other. They are designed by people who know what the other one does.