Pilots vs Railway, and What an Idle App Keeps
Both deploy a directory in one command. They part ways at what an idle app keeps.
Railway is the platform most people mean when they say deploying should be one command. Pilots agrees with it about almost everything a developer touches on the first day, and differs underneath, in what a machine is and what it keeps when nobody is using it.
Everything said about Railway here was read from its own documentation in September 2026, and each claim links to the page it came from.
What the two agree on
- A directory deploys in one command. `railway up` and
pilot deployboth take the directory you are standing in. Neither asks for a Dockerfile first, and both use one when it is there. - A push deploys. Both connect a GitHub repository and build on a push.
- Agents are first-class. Both ship a CLI and an official MCP server, so an agent can run the platform without a browser.
- Sandboxes exist. Railway ships sandboxes for coding agents on every plan. Pilots has had them from the start.
A container or a microVM
Railway runs a service as a container. Its documentation says that under the hood, services are containers deployed from an image, and those containers are what Railway orchestrates. Its sandboxes are a different thing underneath, isolated Linux VMs created on demand.
Pilots runs everything as a microVM, a small virtual machine with a kernel of its own, and those machines are what Pilots orchestrates. A sandbox and a production service are the same kind of machine. Most of what follows on this page comes from that. A machine that is a whole computer can be frozen with its memory, captured as it stands, and woken on another host.
What sleep keeps
Railway can put an idle service to sleep. Its documentation is direct about the cost. Waking is a cold boot, and the first request to a slept service may return a 502. The process starts again from nothing, so whatever it held in memory is gone.
On Pilots, suspend is a freeze rather than a stop. Memory and disk are captured, every process resumes where it was, and a request that arrives while the machine sleeps is held while it wakes rather than answered with an error page. A cache your app warmed before it slept is still warm. That is the default for a service replica with no traffic, not a mode you opt into.
One primitive or two
Railway offers sandboxes and services on one platform, as two different things underneath. A sandbox is a VM and a service is a container, billed at different rates and with separate lifecycles. Its documentation says that for production traffic you deploy a service, so an experiment that turns out to matter is deployed again.
On Pilots a sandbox and a production replica are the same machine with different lifecycle settings. pilot promote turns a sandbox running your image into a service in one call. Nothing is rebuilt or copied, and the URL does not change, so every link anybody already shared keeps working.
What a checkpoint holds
Railway's sandbox checkpoint and fork copy the disk. Its documentation says that files are preserved but running processes and memory are not.
A Pilots checkpoint captures the machine as it is at that instant, memory included. A restore puts back the same processes and the same open files, and a fork starts a new machine from that exact moment.
What a sandbox is for
A Pilots sandbox is a small computer, and it is good for whatever a computer is good for. It runs Linux with a kernel of its own and gives you root, so you install what the job needs.
An agent can work in one with its permission prompts switched off, because the worst it can break is a machine you were going to throw away, and not your laptop. A fleet of them can each open a real browser and use your product the way a person would, reporting what broke, while the product itself is measured under all of them at once.
What Pilots is built for
- You want a fleet of disposable computers to test a product the way its users will use it.
- Your app is idle most of the time and should use no compute while it is, without paying a cold boot and a possible error on the way back.
- You want a sandbox that remembers what it was doing, processes and all.
- You want an experiment to become production without a new address.
- You want one command between the sandbox and production.
- You want a checkpoint to mean the whole machine, so a risky step can be undone exactly.
On databases the two are closer than they look. Railway says its database templates are unmanaged, and Pilots says the same of its own. The platform writes the configuration, the volume and the backups, and you operate the database.
Questions people ask
Does Railway use containers or virtual machines?
Both. Railway services are containers and Railway sandboxes are Linux VMs. Pilots runs sandboxes and services alike as microVMs.
Does Railway scale to zero?
Yes. Waking a slept Railway service is a cold boot, and its documentation says the first request may return a 502. Pilots wakes a machine with its memory intact and holds the request meanwhile.
Can I move from a sandbox to production on Railway without changing the URL?
No. A Railway sandbox is a VM and a service is a container, so production means deploying a service. On Pilots, pilot promote does it in place and the URL stays the same.
Is Pilots a replacement for Railway?
Yes. Pilots deploys an app from a directory or a repository the same way, keeps its memory while it sleeps, and runs your sandboxes on the same platform.
Every comparison, or install the CLI and hold Pilots against your own app.