PandaStack vs Railway: an honest comparison
Railway is, by most accounts, the nicest developer experience in this category. The canvas view of your services, the way databases and apps wire themselves together, the speed of getting from nothing to deployed — it's genuinely well designed, and a lot of teams are happy there and should stay.
PandaStack solves an overlapping problem with a different substrate: each app runs in its own Firecracker microVM rather than a container. This post is about when that substrate difference actually matters, which is less often than I'd like and more often than you might think.
The unit of deployment
On Railway you compose a project from services — an app, a database, a worker — that talk over a private network, and you operate that project over months. It's a graph of long-lived things you deploy to.
PandaStack has that shape too for apps, but the underlying primitive is a microVM your code can create at runtime through an API. That means a machine isn't only something you deploy — it's something your backend can spin up in about 179ms because a customer clicked a button, and destroy 40 seconds later. Apps are a product built on top of that primitive, which is why ephemeral environments feel different here: they're the base case, not a special feature.
What's between your app and its neighbours
Containers isolate with kernel namespaces and cgroups. It's a real boundary, it's what most of the internet runs on, and it is fine for your own trusted code. What it isn't: a boundary designed to hold against hostile code. Kernel escape bugs exist, get CVEs, and are the reason no container platform lets you load kernel modules.
A microVM puts a hypervisor between tenants and gives each app its own kernel. That buys two things. Security, if you're running code you don't control. And capability: inside your own kernel you can run privileged containers, use device mapper, mount filesystems, rewrite iptables, run nested VMs. Every 'operation not permitted' you've hit on a PaaS is downstream of the shared kernel.
Ephemeral environments and the speed threshold
Every platform will give you a preview environment per pull request. The interesting question is what it costs in time and money, because that determines whether people use them for anything beyond a final review.
Snapshot-restore changes the threshold. Creating a machine is p50 179ms, p99 around 203ms — every create restores a baked snapshot rather than cold-booting, and only the first spawn of a template pays a roughly 3-second cold boot. At that speed, a test suite can create a machine per test file. A CI job can fan out twenty isolated environments and tear them down. A demo can provision a fresh instance per prospect.
Forking makes it stranger. A fork inherits its parent's memory and disk copy-on-write: same-host forks land in 400 to 750 milliseconds, cross-host 1.2 to 3.5 seconds since the memory image has to move first. So you can boot an environment, run migrations, seed data, warm caches, and then fork that fully warmed state twenty ways — each fork starting from the expensive setup rather than repeating it. There's no container equivalent, because containers don't have memory state to fork.
The cost shape
Usage-based pricing, which Railway is known for, is a big improvement over paying for provisioned instances. The remaining question is what counts as usage — specifically, whether an idle app costs anything.
PandaStack's answer is that an idle app sleeps: state captured, VM deleted, restored on the next real request. Two caveats I'd rather state than have you discover. Wake from a local image is sub-second; wake on a cold host is tens of seconds. And the idle timer has to ignore automated traffic — we shipped a version where it didn't, and apps that were perfectly capable of sleeping never did, because an uptime monitor pinged them every sixty seconds. That bug is invisible except on the invoice.
Where Railway is the better choice
- Developer experience. Railway's project canvas, service wiring, and templates are excellent, and 'my team enjoys using it' is a real engineering benefit, not a soft one.
- The services catalogue. Databases, caches, queues, and one-click templates for common stacks, all wired into private networking. Our catalogue is narrower — managed Postgres, functions, scheduled jobs — and younger.
- Maturity. Railway has operated at scale for years. We have less history, and if your app is your revenue that should weigh heavily.
- Per-service sizing. You pick resources per service. On a snapshot-restore platform, RAM and vCPU are properties of the baked template rather than a slider, which is simply less convenient for ordinary sizing decisions.
- Standard apps. If you're deploying your own trusted code with no unusual system requirements, the container boundary is sufficient, and switching platforms for an isolation property you don't need is a waste of a week.
Where the microVM model wins
- Untrusted or generated code. If your product runs user-supplied scripts, marketplace plugins, or LLM-written code, a shared kernel is the wrong boundary and no amount of platform polish changes that.
- Kernel-level requirements. Docker-in-Docker, kernel modules, device mapper, nested virtualisation, custom network namespaces.
- Environments as a runtime primitive. When your application itself needs to create isolated machines — per customer, per job, per agent task — a deploy-oriented platform is the wrong shape and an API that returns a VM in 179ms is the right one.
- Fork-based workflows. Warm an environment once, branch it many ways. Useful for test parallelism, agent exploration, and any 'try N variants from the same expensive starting state' workload.
- Compliance conversations. 'Each tenant runs in a separate virtual machine with its own kernel' is a much shorter security review than explaining container namespaces to an auditor.
What both do the same
It's worth being clear about the large overlap. Both connect a git repo and deploy on push. Both detect frameworks and pick sensible defaults. Both stream build logs, keep deployment history, roll back, manage environment variables, and give apps a stable URL with TLS. Both support custom domains.
# The everyday loop is unremarkable on both platforms. Here it is on ours.
curl -sS -X POST https://api.pandastack.ai/v1/apps \
-H "Authorization: Bearer $PANDASTACK_API_KEY" \
-H 'Content-Type: application/json' \
-d '{"name":"web","git_url":"https://github.com/acme/web",
"git_branch":"main","auto_deploy":true}'
# Where it diverges: the same API creates raw microVMs your app can drive
# at runtime -- not something you deploy, something your code creates.
curl -sS -X POST https://api.pandastack.ai/v1/sandboxes \
-H "Authorization: Bearer $PANDASTACK_API_KEY" \
-H 'Content-Type: application/json' \
-d '{"template":"base","ttl_seconds":600}'That second call is the actual difference. Not a nicer deploy — a different unit of compute that your application can allocate the way it allocates memory.
Choosing
Deploying your own web app and database, want it to feel good, don't have unusual isolation needs: use Railway. It's a better fit for that job than we are today, and pretending otherwise would waste your time and mine.
Come to a microVM platform when the box matters: untrusted code, kernel capabilities, per-tenant isolation you have to justify to a security reviewer, or an application that needs to create isolated environments as a runtime operation. Those aren't preferences you can satisfy with a better container — they're the cases where the substrate is the requirement.
Frequently asked questions
What is the difference between PandaStack and Railway?
Railway runs your services in containers on a polished project-oriented platform where you compose apps, databases, and workers into a graph you operate over months. PandaStack runs each app in a Firecracker microVM with its own kernel, and exposes the underlying microVM as an API primitive your own code can create at runtime in about 179 milliseconds. The overlap is large — both do git-push deploys, framework detection, build logs, rollbacks, environment variables, custom domains — and the divergence is the isolation boundary and the ability to treat an isolated machine as something your application allocates rather than something you deploy.
When should I choose Railway over a microVM platform?
When you are deploying your own trusted code, want a broad catalogue of managed services wired together with good developer experience, and have no unusual system requirements. Railway's project canvas and service templates are excellent and a team that enjoys its tooling ships faster, which is a real benefit rather than a soft one. It also has more operational history, and per-service resource sizing is simply more convenient there than on a snapshot-restore platform where RAM and vCPU are properties of a baked template rather than a slider.
How do ephemeral preview environments differ on microVMs?
Every platform offers a preview environment per pull request; what changes is the cost in time. Creating a microVM through snapshot-restore is roughly 179 milliseconds at the median, so environments stop being a batch operation you schedule and become something you do in a loop — a machine per test file, twenty isolated environments fanned out from a CI job, a fresh instance per sales demo. Forking goes further: a fork inherits the parent's memory and disk copy-on-write in 400 to 750 milliseconds on the same host, so you can warm an environment once with migrations and seed data and then branch that warm state many ways instead of repeating the setup.
Does an idle app cost money on either platform?
On PandaStack an idle app sleeps: its state is captured, the VM is deleted, and the next genuine request restores it. Wake from an image on the local host is sub-second; wake on a cold host where the image must be fetched over the network is tens of seconds. The critical detail on any platform is what counts as activity — we shipped a version where uptime monitors and security scanners reset the idle timer, which meant apps capable of sleeping never did, and the only visible symptom was the invoice. Railway's usage-based pricing is well regarded but its idle behaviour is theirs to document, so check their current pricing page.
What can I run in a microVM that I cannot run in a container PaaS?
Anything requiring kernel-level privileges, because you own the kernel rather than sharing the host's. That includes Docker-in-Docker and privileged nested containers, kernel modules, device mapper and other block-layer tooling, filesystem mounts, direct manipulation of iptables and network namespaces, and nested virtualisation. If you have ever hit an 'operation not permitted' on a managed container platform, that error is downstream of the shared kernel, and a VM removes the entire category rather than working around individual cases.
49ms p50 cold start. Fork, snapshot, and scale to zero.