App hosting in 2026: Fly, Render, Railway and microVMs

App hosting stopped being one category some time in the last two years. The four platforms below all answer “where should this process run”, and they answer it with different units, different billing shapes, and different opinions about what happens when nobody is calling your app.

One of the four is ours, which is disclosed rather than hidden, and it goes first because it is the proposition the other three are a useful check against. Every competitor number here comes from that vendor’s own pricing or documentation, cited inline and checked on 6 August 2026.

What you are actually choosing between

Five axes do most of the work, and they are not the ones the landing pages lead with.

The pricing shape: flat monthly instance, metered usage, or preset VM. What happens on idle, which is where the surprises live. The isolation boundary, and whether the vendor publishes one. Region coverage. And how much of the rest of your stack comes from the same bill.

That last axis is the one we built for, so start there.

Scalix Run

Scalix Run deploys containers on microVMs. Each deployment gets its own kernel rather than sharing one with other tenants, and that is the default rather than a premium tier. Firecracker boot measures about 76 ms on our hardware, VMM to userspace. That figure is the boot of the microVM in isolation. It is not a create-to-ready time and it is not a function cold start, both of which are longer numbers, and it would be dishonest to present it as either.

You deploy from a source directory with the runtime detected from package.json, requirements.txt, go.mod or Cargo.toml, from your own Dockerfile, or from a prebuilt image. Every deploy is an immutable revision. Health checks gate the cutover, so a build that fails to come up never takes traffic. Rollback to any previous revision is one command. The service URL does not change between deploys.

Sizing runs from half a vCPU with 256 MB up to 4 vCPU with 8 GB, a lower ceiling than any of the other three. Metering is per vCPU and per GiB, billed per second while a service is awake, with concurrency-based autoscaling and a minimum instance count you can set to zero; the rates are on the pricing page. Set that floor to zero and, when nothing is calling the service, no compute meters.

Note the shape of that meter, because it decides whether our rate is comparable to anyone else’s. It prices allocated capacity while the service is awake, not measured consumption. Against a purely consumption-metered vendor, a spiky workload may well cost less there and a steady one less here. Model your own traffic rather than either headline number.

What sits on the same key

The per-deployment kernel is the part people ask about first, but it is not the argument. The argument is that the service is not on its own.

A Scalix Run service sits beside managed Postgres on 16, 17 or 18 with branching and point in time recovery, object storage, serverless functions, app auth, DNS and first party inference. One credential authorises all of it, and one usage ledger meters all of it, because it was written as a single system rather than assembled from parts that later had to agree with each other. That is worked through in one key, one bill and built, not assembled.

In practice that means the thing you deploy, the database it queries, the bucket it writes to and the model call it makes are one integration rather than four, and they reconcile against each other on one bill. Long-running services also make Run a reasonable place to host an MCP server or an agent loop, which are the same shape as any other always-on process, and the control plane is operable by an agent as well as by a human.

The limits, plainly

One region, in the EU, with India next. That is the fewest of the four and the first thing to check against your latency requirements.

No managed Redis, Kafka or CDN. A 4 vCPU ceiling on a single service, which is lower than the other three and rules out the largest single-box workloads.

We publish uptime at status.scalix.world and support is direct access to the people who wrote the platform. We do not sell support tiers or availability commitments, and if procurement requires one on paper, that gap is real and the other three have an answer we do not.

Two engineers built and operate this. That is why it is one system, and it is also a concentration risk you should price into the decision rather than take on faith.

Fly.io

Fly optimises for direct control of the machine. Their unit is the Machine, a VM whose lifecycle, resources and region placement you drive yourself through a REST API or flyctl, and Fly’s engineering writing has described the underlying thing as approximately OCI containers repackaged as KVM microVMs, which is a more useful description than either “container” or “VM” alone.

The headline strength is reach plus a mature first party database. Fly Managed Postgres is documented in twelve regions on Postgres 16, with high availability, backups and connection pooling on every plan. Their docs also list what is not there yet, including version upgrades and migration tooling, which is a good habit more vendors should copy.

Billing shape: preset CPU and RAM sizes billed by the hour. Stopping a Machine is the honest version of scale to zero, in that compute stops and storage does not: their pricing docs state plainly that a stopped Machine keeps billing for its root filesystem storage. Object storage and Redis on Fly are operated by third parties rather than by Fly, which gets you to specialist products quickly and leaves you carrying the seams between them.

Render

Render optimises for predictability. You buy a sized instance at a flat monthly price, billed “prorated by the second”, and it runs. Nothing about the bill is a surprise, which is the entire pitch and a good one.

The headline strength is the depth of the managed data services. Render Postgres is first party with point in time recovery on paid tiers and high availability from Pro upward, there is a Redis-compatible key value service beside it, and around those sit static sites on a CDN, cron jobs, preview environments and infrastructure as code without you assembling any of it.

Billing shape runs opposite to the rest of this list, so read it carefully. Paid instance types do not spin down at all, which means a service that receives no traffic for a week still bills its full monthly rate. Only the entry instance type spins down, after “15 minutes without receiving any inbound traffic”, and waking “takes about one minute”. Five regions: Oregon, Ohio, Virginia, Frankfurt and Singapore, fixed once a service is created.

Railway

Railway optimises for usage-shaped bills on hardware it owns, which makes it the only one of the four besides us not renting from a hyperscaler. Railway Metal is described in their docs as “hardware that we own and operate in datacenters around the world”, and on whether they will stay on a public cloud the answer is direct: “No. We are migrating completely onto Railway managed hardware.” Four regions carry the Metal name: California, Virginia, Amsterdam and Singapore.

Billing shape: per second consumption drawn against monthly plan credits, at published per second rates for vCPU and memory.

Idle handling is a feature called Serverless, and its mechanism is unusual enough that you should check it against your own app rather than assume. Railway watches outbound packets, not inbound: “Inbound traffic is excluded from considering when to sleep a service.” An open database connection pool, framework telemetry or an NTP client is enough to keep a service awake indefinitely. Their docs also warn that the first request after sleep “may return a 502 Bad Gateway response”.

One thing to know before assuming a managed database: Railway’s Postgres templates are, in their own words, “considered unmanaged, meaning you have total control over their configuration and maintenance”. Backups are yours to arrange. That is more control and more work, and which you want is a genuine preference rather than a defect.

Isolation, honestly

Fly and Scalix both publish microVM models, so on that axis the two of us are close and neither should be selling it as a differentiator against the other.

Render and Railway describe services and containers in the documentation we read, and we found no published statement either way on the kernel boundary between tenants. Absence of a published claim is not evidence of a weaker one, and inferring an isolation property from a marketing page is a bad habit. If a specific boundary matters to you, ask each vendor directly and get the answer in writing.

The neutral version of the argument: shared-kernel containers are good isolation and hold up for the overwhelming majority of workloads. A per-workload kernel matters most when the code being executed was decided at runtime rather than at review time, which is why it comes up far more often now that agents run generated code.

Idle behaviour, side by side

This is the axis that produces the most surprise bills, and all four differ.

Scalix Run: minimum instances can be set to zero, and compute meters only while an instance is running. Anything you keep, such as stored data and object storage, keeps billing whether the service is awake or not.

Fly: stop a Machine and compute stops at subsecond speeds, but the root filesystem keeps billing while stopped.

Render: paid instance types run continuously and bill their monthly rate regardless of traffic. Only the entry type spins down, after 15 minutes without inbound traffic, waking in about a minute.

Railway: Serverless sleeps a service after 10 minutes with no outbound packets, and a connection pool or telemetry defeats it. The first request after sleep may return a 502.

None of these is wrong. They are four different bets about whether predictability or elasticity is the thing you are buying.

Where each fits

Scalix Run, if you want a per-deployment microVM kernel and scale to zero on the same key as a managed Postgres, object storage, functions and inference, and if EU operation matters to the decision. Not if you need more than one region this quarter, a support contract on paper, or more than 4 vCPU in a single service.

Fly, if you want direct lifecycle control over VMs, a first party managed Postgres in the same region as your app, or the widest region coverage of the four.

Render, if you want a flat monthly bill you can forecast and the deepest managed data services of the four, with preview environments and infrastructure as code included rather than assembled.

Railway, if you want usage-shaped bills and a project graph where the database is a service you fully control. Not if you want a managed database, because their own docs tell you it is unmanaged.

The test that settles it

Deploy the same app twice. Watch what the bill does over a week of your actual traffic rather than a synthetic benchmark, and time the wake path after an idle period. Both are afternoon experiments, and both beat any comparison table, this one included.

If you want to run that experiment against microVMs with scale to zero, Scalix Run takes a source directory or an image, the rates are on the pricing page, and the database that sits beside it is Scalix Nova. If one of the other three fits your workload better, that is a good outcome and we would rather you found out in week one. Tell us what you measured on Discord.