Your app on a URL, by asking your agent
Ask your agent to deploy, or run one command yourself. There is nothing to configure. The whole app goes live, database and background jobs included, and a new version takes over only after it answers.
Any app, with or without a Dockerfile
Pilots recognises the common frameworks and builds them. When you have a Dockerfile or a compose file, it uses that.
$ pilot deployDockerfile: checkout in .plan: 1 services in app checkoutcheckout buildingcheckout RUN npm cicheckout built bld_5e0c2a7fcheckout release rel_91d4b3e6 acceptedSERVICE URLcheckout https://checkout.pilotrun.appLogs an agent can act on
When a build fails, the log says which step failed and why, in a form an agent can read, fix and try again.
Frameworks it knows
WebJs, Next.js, Rails, Django, FastAPI, Laravel, Go, Rust and more, with nothing to configure. For anything else, your agent writes the Dockerfile.
The whole app, not only the web server
A database, a background worker and a scheduled job deploy together, from one file your agent writes for you.
A folder or a repository
Deploy a folder from the command line, or connect a repository once and let each push deploy itself.
Nothing takes traffic until it answers
A new version has to answer before it receives any visitors. Until it does, the old one keeps serving.
-
1
Start the new version beside the old
Both exist at once. Nothing has moved yet.
-
2
Wait for it to answer
The new version answers its health check. If it does not, the deploy stops here and the old version is untouched.
-
3
Send visitors to it
Visitors reach the new version. The address does not change.
-
4
Keep the old version
It is kept, so rolling back needs no rebuild.
Custom domains
Point your domain at Pilots and a certificate is issued for it.
More copies when it is busy
More copies start when the app is busy and stop when it is quiet, down to a minimum you set.
Asleep when idle, by default
A service with no visitors goes to sleep. The first request afterwards is held while it wakes, and a database stays awake while anything is connected to it.
What promotion adds
A sandbox becomes a production service by gaining versions, a health check and more copies. Everything it already did, it still does, at the same address.
| Capability | As a sandbox | After promote |
|---|---|---|
| Its URL, its state and its agent token | yes | unchanged |
| Suspends when idle, wakes on the next request | yes | unchanged |
| Exec, a terminal, and files in and out | yes | unchanged |
| Checkpoint, and restore in place | yes | unchanged |
| A version to deploy, and to roll back to | no | added |
| A new version that takes over only after it answers | no | added |
| More than one copy, with requests spread across them | no | added |
| Copies started by load, and stopped when it passes | no | added |
| A domain of your own, with its certificate | no | added |
| When it sleeps is decided by | a timer | how busy it is |
A promoted service still sleeps when nobody is using it, and it never drops below the number of copies you asked to keep awake.
The same is true of a preview for a pull request. It gets an address of its own, sleeps when nobody is looking at it, and is destroyed when the branch merges.
The tests that run before the merge can run here too. A GitHub Actions job with
runs-on: pilots gets a fresh computer of its own for as long as the job runs,
made from your team's runner image, and is billed by the second like everything else.
How runners work.
Where application data actually belongs
A checkpoint captures a computer at one moment, which is the wrong tool for a database. A volume is the right one.
A volume is stored away from the computer running your app, so it survives that computer failing. Every write to a volume is safe the moment it returns. Files outside a volume are saved within 60s, which is fine for everything that is not a database.
This is tested, not assumed. The test suite stops a computer and brings its data back on another.
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.