This month three platforms have described moving tenant workloads from containers to per-tenant kernels: Netlify to Unikraft MicroVMs on 29 September, DigitalOcean to Firecracker on 15 October, and Railway, whose documentation now carries a separate rate card for "Railway's virtual machine primitive". Most of that coverage has been about what the change is. Railway's page is the first on this beat to put a number on what the primitive costs to run — in the vendor's own catalogue, next to the container rates it replaces for those workloads.
Everything below is from docs.railway.com/reference/pricing, read on 18 October 2026. The figures are Railway's, about Railway; this post does not set them against anyone else's price list, including ours.
Two rate cards on one page
Railway bills resource usage on top of a subscription fee. The container rates are the ones most Railway users know:
| Resource | Container rate | VM rate |
|---|---|---|
| RAM | $10 / GB / month | $50 / GB / month |
| CPU | $20 / vCPU / month | $50 / vCPU / month |
| Network egress | $0.05 / GB | $0.05 / GB |
Five times the RAM rate, two and a half times the CPU rate, the same egress. The container table also carries a volume storage line ($0.15 / GB / month); the VM table does not list one.
The scope sentence is the load-bearing one, so here it is in full: "Workloads that run on Railway's virtual machine primitive, such as sandboxes and cloud agents, are billed at VM rates instead of the container rates above." The VM rates are not Railway's general app-hosting price. They apply to the workloads Railway runs on VMs — sandboxes and cloud agents are the examples the page gives — and a web service deployed the ordinary way is still on the container card. Read the rest of this post with that limiter attached.
Why the VM costs more while doing nothing
The interesting part is not the multiplier but the sentence explaining what is being metered: "Charges follow measured CPU use, memory in use (including the operating system and filesystem cache), and outbound traffic. Memory remains billable while a VM waits for work, along with any background CPU use or outbound traffic. Once destroyed, the VM incurs no further compute usage."
That is the cost of a kernel per tenant, written as a billing rule. A container shares the host's kernel and page cache, so when your process is idle there is very little memory that is unambiguously yours. A virtual machine carries its own operating system and its own filesystem cache, and that memory is in use whether or not your code is doing anything. The platform cannot give it back to anyone else while the VM exists, so it bills it — per second, the page says, "and draws from the same included usage as the rest of your plan". The page's own advice follows directly: "destroy sandboxes when you're done or rely on the idle timeout, and prefer checkpoints over long-lived sandboxes for state you reuse".
None of that is an argument that VMs are the wrong primitive for the job. For a sandbox that runs untrusted code or an agent that needs its own OS, a kernel of your own is the point, and you pay for the isolation you asked for. The lesson is narrower: the monthly figures on the VM card are, in the page's words, "what a VM would cost if it held a full GB or kept a full vCPU busy for the entire month", and the memory half of that is held the whole time the VM is alive. Idle is not free on that card the way it tends to be on the container one.
The rest of the sheet, for context
Because this page is server-rendered it is also the first Railway surface where the plan structure can be read rather than inferred, so the basics are worth setting down once. Four plans plus a trial: Free at $0, Hobby at $5 a month, Pro at $20 a month, Enterprise at a custom price. The subscription on Hobby and Pro is a usage credit rather than a pure platform fee: "The Hobby plan includes $5 of resource usage per month", and likewise $20 on Pro, with the page's own worked example — usage of $3 bills $5, usage of $7 bills $7 — and its own answer to the obvious question: "Even if you do not use the $5 in usage (CPU, Memory, egress), you always pay the $5 subscription fee."
There is also a deployment-image retention ladder on the same page, of the same shape as the one we wrote about when Vercel changed its default: Free and Trial 24 hours, Hobby 72 hours, Pro 120 hours, Enterprise 360 hours. "Railway retains images for a period of time after a deployment is removed. This is to allow for rollback to a previous deployment." Different vendor, same lesson: your rollback window is a number in a policy, and it is worth knowing which number.
What to take from it
If you run on Railway, the practical reading is in their own sentences: ordinary services stay on the container card; anything you run as a sandbox or cloud agent is on the VM card, is metered per second, and keeps billing memory until it is destroyed, so idle timeouts and checkpoints are the tools that control the bill. If you run anywhere else, the general point survives the vendor: when a platform tells you it has moved a workload to its own kernel, the honest follow-up question is what that kernel's memory costs while it waits — and this is the first place a vendor has answered it on a page you can grep.