Fly.io vs Railway vs a $5 Droplet: What the No-Container Counter-Narrative Gets Right — and Where It Breaks at the Second Service

He budgeted $20 a month, opened a bill for $286, and spent the following weekend deciding between Fly.io, Railway, and a $5 DigitalOcean droplet running a binary on systemd. That is the setup of Tural Allahverdiyev's June 2026 essay "Your PaaS Bill Lied to You," and its ending is refreshingly honest: after comparing every platform, the author admits the cheapest option might be skipping the PaaS entirely. No build pipeline. No image registry. Just scp a binary and write a unit file.

He has a point — for exactly one app.

This post gives the no-container counter-narrative a fair hearing, with real 2026 numbers, and then asks the question the essay only gestures at: what happens when you add a second service?

The honest price table: one small app, three bills​

Take a typical small production app: one web service (roughly 512MB–1GB of RAM), one Postgres database with a 10GB volume, and about 50GB of monthly egress. Nothing exotic — a SaaS MVP, a side project with users, an internal tool. Here is what it costs on each option in 2026:

Two footnotes before anyone screenshots this table. First, the "$5 droplet" is a $6 droplet now: DigitalOcean's basic 1 vCPU / 1GB / 25GB SSD box costs $6 a month in 2026 (a $4 512MB tier exists but is too tight for app plus database). The essay's framing survives the correction — $6 flat is still the cheapest line in the table.

Second, Railway's number is usage-driven: Hobby ($5 minimum) versus Pro ($20 minimum) only changes the floor and the included credit, while compute at roughly $0.00000772 per vCPU-second and memory at $0.00000386 per GB-second does the real damage for always-on services. An allocation of half a vCPU and half a gig running the full month is about $15 before the database or a byte of egress enters the picture. That is precisely how a $20 budget becomes a $286 bill: the meter runs on allocated resources, not requests.

The headline result: for one always-on app, the droplet wins on price by 2–5x, and Fly.io's per-VM-second billing lands in the middle at roughly $10. The counter-narrative is arithmetically correct. Now let's steelman it properly.

What the droplet genuinely wins​

Strip away the platform and several costs vanish at once — not just money:

• No build pipeline. There is no Dockerfile to maintain, no builder image to wait for, no build minutes to pay for. go build or cargo build --release on your laptop, scp the binary, systemctl restart app. A deploy takes seconds and the only artifact is a file.
• No image registry. No base-image CVEs to patch, no layer cache to warm, no registry credentials to rotate. The attack surface is one binary plus the host OS.
• A bill that fits in a tweet. $6, flat, predictable to the cent. No egress tiers ($0.02 versus $0.04 versus $0.12 per GB depending on region), no per-second meters, no surprise multipliers. The 1TB of included transfer covers 50GB twenty times over.
• The whole machine. Need to tune Postgres shared_buffers, run a cron job, mount a volume, install ffmpeg? It's your box. No platform allowlist, no support ticket, no "that feature is on the roadmap."

For one app run by one person who is comfortable with SSH, this is not a compromise — it is arguably the better setup. Fewer moving parts, lower bill, full control. Every complaint about PaaS pricing in 2026 is, at bottom, a complaint that the platform charges $28 for something a $6 box does fine.

But notice what the sentence above smuggled in: one app, one person. The essay's real question was never "which is cheaper for deploy number one." It is what survives deploy number two.

The second-service breakpoint​

Add a second service — a background worker, an API behind the web app, a staging copy — and every line the droplet won starts charging interest. Not in dollars, in hand-maintained machinery:

Rolling deploys become your code. On Fly.io and Railway, deploy means the new version health-checks before traffic shifts; a bad release rolls back. On the droplet, systemctl restart is a hard cutover with downtime measured in restart time, and a bad binary means SSH-ing in to restore the old one. Blue-green on one box is a hand-rolled reverse-proxy dance (two unit files, two ports, a Caddy or nginx flip) that you now own forever.

Preview environments don't exist. Every PaaS in this comparison mints a per-PR URL automatically. On the droplet, a preview environment is a second unit file, a second port, a second database, a second DNS record — per pull request — plus the discipline to tear it all down. Most teams simply stop doing previews, and the first outage they would have caught costs more than a year of the price gap.

TLS multiplies. One certbot certificate for one domain is a solved problem. Three services on three subdomains means renewal timers, hook scripts, and failure modes you discover at 3 a.m. when the staging cert expires and takes down a customer demo. Platforms terminate TLS centrally; the droplet makes every service its own certificate authority customer.

Supervision stops being one unit file. Restart=always is lovely until two services share 1GB of RAM and the OOM killer picks the database. There is no memory limit enforcement, no CPU share, nothing stopping the worker from starving the web app — unless you write the cgroup accounting yourself, at which point you are rebuilding, badly, the container runtime you skipped.

Postgres backups are a cron job you wrote. Managed Postgres on either PaaS includes point-in-time recovery. On the droplet, backups are a pg_dump cron entry, an off-box copy script, and a restore procedure you have never tested. The price of this line item is $0 until the day it is everything.

None of these is impossible. Each is a weekend. Five weekends later you have rebuilt a worse PaaS, undocumented, tested only by outages — and you are still the only person who can operate it. That is the breakpoint: the droplet wins while the system fits in one head and one unit file, and it loses the moment the system needs handoffs, previews, or a second service with its own lifecycle.

When the answer flips​

The honest table has a sensitivity analysis, because "it depends" is only useful with numbers attached:

• Egress-heavy app (500GB/mo). Fly.io adds ~$10, Railway adds ~$25 on top of compute, and the droplet still costs $6 — DigitalOcean's 1TB allowance absorbs it. If you serve video, large downloads, or an image-heavy site, the droplet's flat transfer is a genuine structural advantage, and even a second droplet ($12 total) beats both PaaS bills. Price flips hard toward the VPS.
• Idle side project. An app with traffic a few hours a day can use Fly.io's auto-stop to idle near ~$2 plus volume costs, undercutting the droplet's always-on $6. Railway has no equivalent — allocated resources bill whether or not requests arrive — so the idle project is the one workload where Fly.io beats the box. Utilization flips the winner.
• A team of three. The moment two more humans deploy, the PaaS buys something the droplet cannot: per-developer preview URLs, deploy logs anyone can read, rollbacks anyone can click, and no shared SSH key to the one box that runs everything. The $22-a-month gap between Railway and the droplet is about fifteen minutes of one engineer's time. Headcount flips the question from "what's cheapest" to "what's operable."

Notice the pattern: every scenario that favors the droplet is a scenario with one app, one operator, and steady traffic. Every scenario that favors a platform involves a second thing — a second service, a second developer, a second environment.

The verdict: ask about deploy #2, not deploy #1​

Allahverdiyev's essay is right that PaaS bills lie by meter — allocated-but-idle resources, egress tiers, and minimums stack into totals nobody predicted from the pricing page. And the droplet is right that one app on one box needs none of that machinery. Both can be true because they answer different questions.

So here is the decision rule, stated as the question that actually decides it: describe your second deploy, not your first. If the honest answer is "there isn't one — one binary, one operator, steady traffic," take the $6 box and never look back. If the answer involves a worker, a staging environment, a teammate, or a preview URL, price that system: the droplet's bill stays $6 while its operational cost compounds per service, and the PaaS bill that looked inflated for one app starts looking like the cheapest ops hire you will ever make.

There is a fourth answer worth naming: the price gap exists because the PaaS rents you someone else's machines by the second. A self-hosted platform on hardware you own keeps the droplet's flat economics while restoring deploys, previews, and TLS as built-in primitives instead of weekend projects. That is the gap Bex.co is built for — push a git repo, get a running HTTPS service on machines you own, with Render-compatible APIs your existing tooling already speaks.

The $286 bill was never really about $286. It was about discovering, one line item at a time, what your first deploy never told you the second one would cost.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.