Hosted vs BYOC vs Self-Hosted: Price Your PaaS Exit in Three Columns

Most teams price a PaaS exit the way they price a holiday: they look at one number — this month's hosted bill — and compare it against vibes about what the alternative might cost. Qovery's September 2026 Heroku-alternatives comparison does something more useful. It splits the market into three cost models — hosted, bring-your-own-cloud (BYOC), and self-hosted — and prices all three side by side from the vendors' own pages. That framing is the honest way to scope an exit, because the three models don't just charge different amounts; they charge for different things.

Here is the thesis before the spreadsheet: price the same workload in all three columns, including the meters each model hides, or you are not pricing an exit — you are shopping. This post does exactly that for one typical workload, names where each model's meter hides, and shows the scale points where the ranking flips.

The exit spreadsheet: one workload, three bills​

The reference workload is deliberately boring — the shape most teams are actually trying to move: one always-on web service (about 0.5 vCPU / 512 MB), one background worker the same size, Postgres with 1 GB RAM and 10 GB of disk, and roughly 100 GB of monthly egress. Small production app, one team, no GPUs, no multi-region heroics. Every number below comes from vendors' own pricing pages as of September 2026, via Qovery's comparison and the providers' docs.

Two things jump out. First, the BYOC column is not close at this scale — and that is the point of pricing all three columns instead of one. A $2,999/mo control-plane fee amortizes beautifully across fifty services and terribly across two. Second, the self-hosted column wins on cash at every row except the last one, which is exactly the row self-hosting advocates like to leave blank. We will not leave it blank: a few hours a month at a loaded engineering rate is real money, and the next section prices it honestly.

The cloud-floor number inside the BYOC column deserves its own citation. Qovery's own Vercel-alternatives piece puts the AWS baseline at roughly $73 plus about $33 per month before a single container runs — cluster control plane, NAT, load balancer plumbing — on top of load balancers, cross-AZ traffic, and snapshot storage. Your cloud bill is separate, stays in your own account, and starts well above zero. That is not an argument against BYOC; it is an argument against pricing BYOC as "the platform fee" and forgetting the floor it sits on.

Where each model's meter hides​

Every model has a line item that does not appear in the headline price. Name them before they name you.

Hosted: seats, step-ups, and egress. The compute sticker price is honest; the bill grows around it. Team plans add per-seat or per-workspace fees once you outgrow one login. Postgres jumps in discrete tiers — the gap between the ~$6/mo starter and the ~$19/mo 1 GB tier is where "we just need a slightly bigger database" triples the database line. And egress is the classic sleeper: $0.02–0.05/GB looks like nothing until a media-heavy app or an API with large payloads pushes you into hundreds of gigabytes. Railway's own 2026 pricing essay makes this concrete with a worked example — a small web-plus-Postgres shape lands around $18/mo on Railway versus about $28/mo on Render — and the delta is almost entirely which meters each vendor chose, not the compute.

BYOC: the control-plane fee plus your own cloud bill. There are two meters and newcomers consistently price one. The platform fee (per-seat or flat, up to Qovery's $2,999/mo Business tier) buys you the Heroku-like surface. Underneath it, every cloud line item you thought you were escaping is still there — compute, managed databases, load balancers, NAT gateways, cross-AZ traffic, snapshots — except now you keep your Savings Plans and committed-use discounts, which is genuinely one of BYOC's best cost levers. Qovery's BYOC comparison is admirably direct that "those control-plane fees are real," and lists the levers that offset them: spot nodes for non-production, environment auto-stop outside working hours, rightsizing, per-team attribution through cloud tags. Price the fee, price the floor, then price the levers — in that order.

Self-hosted: engineering hours. The hardware is the cheapest line on this page and the labor is the most lied-about. A Hetzner Cloud VM at €8.49/mo genuinely runs the reference workload; a dedicated AX41-NVMe at ~€43–57/mo runs ten of it with 64 GB of RAM and terabytes of NVMe. What it does not include is anyone to apply the Postgres security update, rotate the backups, debug the 3 a.m. disk-full, or rehearse the restore.

Budget a few hours a month for a quiet workload and more during upgrades, multiply by your loaded rate, and put the number in the spreadsheet. Even priced honestly, self-hosting usually still wins on cash at small scale — Qovery itself concedes that "for a handful of small apps, Coolify or Dokploy on one VM will be the cheapest thing you can run." The honest version of that sentence ends with "before you price your own time," and then wins anyway for many teams.

When the ranking flips​

No column wins at every scale. The ranking flips twice as you grow, and knowing roughly where is more valuable than any single total.

One side project: hosted wins. A $2–7/mo machine plus a $6/mo database is below the noise floor of any engineer's time. Spinning up a VM, hardening it, and owning Postgres to save $10/mo is a hobby, not an optimization. Fly.io's per-second Machines billing is purpose-built for this end of the curve: stopped machines bill only for disk, so the side project that idles 20 hours a day costs almost nothing.

A team with a handful of services: self-hosted wins on cash, hosted wins on focus. This is the reference workload's neighborhood, and the table above is the verdict: ~$25–65/mo hosted versus ~$10–60/mo of flat hardware plus a few ops hours. The decision here is not about money — both answers are cheap — it is about whether the team wants to own a small amount of toil in exchange for flat costs that do not twitch every time traffic does. This is also where BYOC looks worst: a control-plane fee sized for twenty users spread over two services is all overhead, no amortization.

Ten-plus services, compliance requirements, or real headcount: BYOC enters, hosted exits. Per-service hosted pricing is linear in the thing that is growing — services, seats, gigabytes — while the BYOC platform fee is roughly fixed and the underlying cloud bill grows at commodity compute rates with your discounts attached. Somewhere in the mid-teens of services (earlier with heavy egress or big databases), the hosted lines cross the BYOC total. Compliance accelerates the crossing: data that must stay in your own VPC or region rules out the hosted column regardless of price, which is precisely the constraint BYOC was built for. Self-hosting stays competitive on cash throughout but its labor line grows with fleet size and audit surface — the team that happily owned one VM at five services often does not want to own the Kubernetes upgrade cadence at fifty.

The meta-lesson: re-run the spreadsheet at 3x scale before you commit. The model that wins today may be the model that punishes you hardest at the scale you are growing into, and the whole point of three columns is that the answer is allowed to change.

Run your own exit math in an afternoon​

The reference workload above is a template, not your bill. Here is the procedure:

1. Inventory what you actually run. Every service, worker, cron job, database, cache, and bucket — plus the review apps and preview environments, which hosted vendors meter and teams forget.
2. Meter real usage for a week. vCPU and RAM actually consumed (not requested), storage growth rate, and egress by destination. Railway's docs walk through turning the Metrics tab into monthly cost; every vendor has an equivalent.
3. Price the same workload in all three columns. Hosted from the vendors' pages, BYOC as platform fee plus cloud floor, self-hosted as flat hardware. Use the table above as the row template.
4. Add each model's hidden meters from the previous section. Seats and step-ups, control-plane fee and cloud floor, ops hours at your loaded rate. The column that looked cheapest in step 3 often stops looking cheapest here — that correction is the entire exercise.
5. Re-run at 3x scale. Triple services, double data, grow egress with your actual growth rate. If the winner changes, weight the decision toward where you are going, not where you are.

One afternoon, one spreadsheet, three columns. That is the whole methodology, and it beats every "we should move to X because the bill feels high" conversation you have had this year.

The exit is a recurring exercise, not a decision​

Pricing is converging on usage-based meters everywhere — per-second Machines, per-GB RAM, per-GB egress — which means the three columns will keep moving against each other as vendors reprice and your workload grows. The team that builds the spreadsheet once and runs it yearly will catch the flip points; the team that treats the exit as a one-time migration will wake up metered in the wrong column. Qovery deserves credit for publishing the three-model framing with real numbers even though its own column loses at small scale — that is what honest vendor content looks like, and it is why the piece is worth building your exit math on.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. If your spreadsheet says the self-hosted column wins, star the repo on GitHub or deploy your first app today.