An agent backend isn't a sandbox. A sandbox runs code an LLM just wrote, for seconds, then throws the filesystem away. An agent backend is the opposite shape: an API that has to answer requests reliably for months, a worker that drains a queue between LLM calls and tool runs, and a Postgres instance that remembers the conversation after a restart. If you've already read our ephemeral sandbox comparison or the Modal vs Cloudflare Containers vs Fly Machines piece, this is the other half of the stack — the part that stays up.

If you read one line: default to Render if you want zero infrastructure decisions, Railway if you want the fastest git-push-to-Postgres experience, Fly.io if you want to control cost on an idle worker with real scale-to-zero, and Northflank if you already know you'll need Kubernetes-level scaling or bring-your-own-cloud later.

Pick X if…#

The pricing models are structurally different, not just different numbers#

Render and Railway both sell you a plan: Render bills per-instance plan tiers by the second, Railway sets a $5/mo Hobby or $20/mo Pro minimum spend with CPU, memory, volumes, and egress metered on top of that floor (Railway pricing model, via docs.railway.com). Fly.io and Northflank sell you raw compute by the second: Fly.io no longer offers plans to new accounts at all, just per-second Machine billing plus $0.15/GB-month for volumes; Northflank bills $0.01667/vCPU-hour and $0.00833/GB-hour, also per second, with a free "Sandbox" tier thrown in for two services, one database, and two cron jobs.

That structural split matters more than any single number. Plan-based pricing (Render, Railway) is easier to forecast and harder to accidentally blow up — you know your ceiling. Usage-based pricing (Fly.io, Northflank) can be cheaper at small scale and scarier at the margins, because a runaway worker or a chatty agent loop shows up as a bigger bill, not a rate limit.

The part everyone gets wrong: workers don't scale to zero the way APIs do#

Here's the non-obvious insight, and it's specific to agent backends: an idle background worker is not the same billing shape as an idle web API on most of these platforms.

Scale-to-zero, where it exists, is almost always triggered by inbound HTTP traffic going quiet. Render's free-tier spin-down and Fly.io's default auto-stop/auto-start both key off requests hitting the app. A web API fits that model perfectly — no traffic, no cost. A background worker that polls a queue or waits on a webhook doesn't have inbound HTTP traffic to key off of, so on Railway and on Render's paid tiers, it just runs — and bills — continuously, whether or not there's anything in the queue.

Fly.io is the one platform where this actually gets solved for a non-HTTP process: auto stop/start on a Machine can be driven by its own idle timer, not just by the Fly Proxy watching for requests, so a worker Machine can genuinely suspend between jobs and resume in well under a second when work shows up (Fly.io autostop/autostart docs). Northflank's autoscaling can also scale job and dev-environment workloads to zero. If your agent backend's worker spends most of its life waiting — which is normal for a queue-driven agent that only spikes on real tool calls — that's the difference between paying for compute 24/7 and paying only when it's actually thinking.

The catch: scale-to-zero saves you compute, not storage. Fly.io volumes bill at roughly $0.15/GB-month whether the attached Machine is running or stopped — your Postgres data doesn't get cheaper just because the worker went idle.

Persistent volumes and managed Postgres#

All four platforms support a managed or attachable Postgres and persistent block storage, but the price and the constraints differ:

None of these are "serverless Postgres that scales to zero" in the Neon or PlanetScale sense — they're all persistent, always-provisioned database instances, which is exactly what an agent backend with conversation history and tool-call logs actually wants.

Cold starts, in context#

Cold starts only matter where scale-to-zero exists. Render's free tier takes about a minute to wake from a 15-minute idle spin-down — fine for a demo, unacceptable for a paying user's first request. Fly.io's Machine resume lands in the few-hundred-millisecond to roughly one-second range, which is usually fast enough to hide inside an agent's own "thinking" latency. Railway's always-on services and Render's paid instances don't have this problem at all, because they don't go to sleep — which is the whole argument for paying for a plan tier instead of chasing the cheapest per-second rate.

The bottom line: this is a tradeoff between operational simplicity (Render, Railway) and cost control on the parts of your stack that are actually idle most of the time (Fly.io, Northflank). Pick based on which one is scarcer for you right now — engineering time, or margin.