Fixed vs pay-as-you-go hosting: find your break-even point

Originally published on the Hubfly space blog.

TL;DR

• What you get: a two-line formula that tells you when a fixed plan beats pay-as-you-go, why memory (not CPU) sets the floor of most bills, and three common apps priced on six platforms (prices from official pages, 21 Oct 2026).
• The short answer: a fixed plan wins when your app is small, steady and fits a plan size exactly. Paying for real CPU use wins when traffic is spiky and CPU sits idle. Sleeping when idle beats both for apps nobody uses at night.
• Who it's for: developers and founders picking a host for an API, a side project or a small SaaS. About 12 minutes to read.

Your app costs $7 a month on one platform, $6.09 on another and $2.19 on a third. All three pages say they're cheap, and all three are right for someone. The trouble is that "usage-based" and "fixed" hide very different meters, and picking the wrong one means paying every month for capacity you never touch, or getting a surprise bill after a traffic spike.

In this guide you'll learn what each pricing model actually charges for, price three common apps on six platforms, and get a two-line formula to find the point where switching models saves you money. It matters because hosting is a bill you pay forever: a $5 difference is $60 a year per service, and most apps run more than one service.

Try it on Hubfly space: the free tier gives you 360 hours a month on the shared tier, no card needed.

The three ways hosts charge you

Every platform in this guide falls into one of three groups. Knowing which one you're on tells you what to watch.

1. Fixed plans (you pay for a size). You pick a box, such as 0.5 CPU and 512 MB, and pay a flat monthly price whether the app is busy or idle. Render ($7 for its "less than 1 CPU" / 512 MB instance), Heroku ($7 Basic dyno, 0.5 GB) and DigitalOcean App Platform ($5 for 1 vCPU / 512 MiB) work this way. Why it matters: the bill is easy to predict, but if your app needs 600 MB you jump to the next size and pay for CPU you didn't need.

2. Pay for what's allocated, while it runs. You still choose a size, but you're billed by the hour or second only while the app is running. Stop it, or let it sleep, and compute billing stops. Fly.io bills started Machines "by the second while running" ($3.69 per 30 days for shared-cpu-1x with 512 MB in its cheapest regions). Hubfly space works the same way: $0.004 per vCPU-hour and $0.002 per GB-hour of allocated memory, billed only while the container is awake. Why it matters: you still pick a size, so oversizing still costs you, but idle hours can be free.

3. Pay for what's consumed. You set a maximum, and the platform meters the CPU and memory your app actually uses. Railway is the clearest example: $0.00000772 per vCPU-second and $0.00000386 per GB-second, which is about $20.29 per vCPU and $10.14 per GB of RAM over a 730-hour month. The Hobby plan has a $5 minimum that includes $5 of usage. Why it matters: an app that averages 5% of a CPU pays for 5%, so you never pay for headroom you don't use.

A fourth group, request-based platforms like Vercel and Cloudflare Workers, bills per request and execution time. It's great for front ends and functions, but most apps that need a database and a long-running process end up on one of the first three, so this guide focuses on them.

The meter nobody talks about: memory

"Pay only for what you use" sounds like your bill drops to almost nothing when the app is quiet. It doesn't, and the reason is memory.

CPU use rises and falls with traffic. Memory doesn't. A Node or Python app loads its code, libraries and caches at startup and holds them until it stops. So a small API can hold hundreds of megabytes of RAM at 3 a.m. with zero requests.

On Railway, 0.5 GB held for a whole month costs 0.5 × $10.14 = $5.07, even if CPU is close to zero. That's already past the $5 Hobby minimum before you've used a single CPU cycle. So when you compare platforms, put your app's idle memory into the math first. It sets your floor.

The same logic applies to allocated platforms in a different way: on Fly.io and Hubfly space you pay for the memory you reserve, not what you use, so reserving 2 GB for an app that needs 500 MB is wasted money every hour it runs.

Find your break-even point in two lines

You don't need a spreadsheet. If you're comparing a fixed plan against consumption pricing, solve this:

consumption cost = (average vCPU used × CPU price per month)
                 + (average GB of RAM held × RAM price per month)

break-even CPU   = (fixed plan price − RAM cost) ÷ CPU price per month

Example: Render's $7 plan vs Railway, for an app that holds 512 MB.

• Railway RAM cost: 0.5 GB × $10.14 = $5.07
• Room left before you hit $7: $7 − $5.07 = $1.93
• Break-even CPU: $1.93 ÷ $20.29 = 0.095 vCPU

If your app averages less than about 10% of one CPU, Railway is cheaper than Render's $7 plan. Above that, the fixed plan wins, as long as Render's smallest instance is enough for your peaks.

To get your own numbers, check your current host's metrics page for average CPU (not peak) and average memory over a normal week.

Three apps, six platforms

All prices below come from each vendor's official pricing page on 21 Oct 2026, for compute only. Bandwidth, databases and disks are left out so the comparison stays like-for-like; see the notes after each table. A "month" is 730 hours unless the vendor states otherwise (Fly.io quotes 30 days).

App 1: a small API that must stay on

A customer-facing API: 512 MB of RAM, averages 0.05 vCPU, can't sleep because a cold start would make users wait.

What this shows: for a small, steady app, allocation pricing with low hourly rates wins, and fixed plans are close behind. Consumption pricing gives you the least advantage here because the app holds its memory all month. Note that Fly.io lists cheaper prices only for its lowest-priced regions, and DigitalOcean includes 50 GiB of outbound transfer in that $5, which matters if your API sends a lot of data.

App 2: an internal tool used a few hours a week

An admin dashboard or staging app: about 50 hours awake a month, 512 MB while running, cold starts are fine.

What this shows: for apps that are idle most of the month, the ability to sleep matters far more than the price per hour. Every platform that sleeps keeps usage under $1, though Railway Hobby still bills its $5 minimum and Heroku Eco is a flat $5. Plans that stay on charge full price for an app used 7% of the time. On Hubfly space, a shared-tier container's cost breakdown in the dashboard reads "Shared tier is free of charge": $0.00 an hour and $0.00 a month. If the tool needs more than 256 MB, a dedicated 0.5 vCPU / 512 MB container costs $0.003 an hour while awake: about $0.15 for 50 hours with Auto Sleep on, or $2.19 left on around the clock.

App 3: a busy API with steady load

A production API that holds 1 GB of RAM and averages 0.6 vCPU all day, every day.

What this shows: once CPU stays busy, paying per vCPU-second of real use stops being a discount. At 0.6 vCPU, Railway costs almost as much as Render's next size up. Using the break-even formula against Render's $25 plan: ($25 − $10.14) ÷ $20.29 = 0.73 vCPU. Above 73% average CPU, the fixed plan is cheaper. Allocated pricing (Hubfly space, Fly.io) wins clearly here, as long as a shared CPU meets your load.

Where each model wins

Be honest about your app's shape before you pick a host. Here's where the other platforms do better than Hubfly space, or better than each other:

• Railway wins on spiky traffic and odd sizes. If your app idles at 0.05 vCPU and jumps to 2 vCPU for an hour a day, consumption pricing bills that hour and nothing else, without you resizing anything. It also gives you hard spending limits, preview environments and built-in database backups.
• Fly.io wins on global reach and scale-to-zero for any size. You can stop any Machine, not just a small free tier, and its reservation blocks cut 40% off for a year's commitment.
• DigitalOcean wins on bundled bandwidth. Each plan includes outbound transfer (50 GiB on the $5 plan), and overage is $0.02 per GiB. For a download-heavy app that's easier to budget.
• Render and Heroku win on predictability and maturity. A fixed $7 or $25 is easy to put in a budget, and both have long track records, managed Postgres and large ecosystems.
• Hubfly space wins on low hourly rates and a free tier that sleeps. You pay $2.92 a month for a full vCPU and $1.46 per GB of RAM when running around the clock, with no seat or project fees. The trade-offs: you pay for what you allocate, so size containers carefully; and the free shared tier is small (0.3 vCPU / 256 MB).

What can go wrong

1. You sized for the peak, not the average. On fixed and allocated platforms, a 2 GB container for an app that needs 500 MB means paying four times too much, every hour. Fix: watch memory for a week, then set the size to your normal peak plus about 25%.

2. Your "sleeping" app never sleeps. Platforms decide an app is idle in different ways. Railway, for example, watches outbound traffic, so a database connection pool, a health-check pinger or a queue poller can keep it awake and billing. Fix: close idle connections, remove external uptime pings on non-critical apps, and confirm on the metrics page that the app actually stops.

3. The bill jumps after a traffic spike. That's consumption pricing doing its job, but it can still hurt. Fix: set a spending alert or limit before you need it. On Hubfly space you can set a monthly budget for each project in its settings, with alerts as you approach it.

Takeaway: match the model to your app's shape

• Small, steady, always on: allocated or fixed pricing. Look for the lowest hourly rate that fits your memory.
• Idle most of the time: anything that sleeps. The price per hour barely matters.
• Spiky and unpredictable: consumption pricing, with a hard limit set.
• Busy and steady: allocated pricing at low hourly rates, or a fixed plan sized exactly.

Read next: Best Heroku alternatives in 2026: 7 options and what they cost and Heroku vs Render vs Railway vs Hubfly space: 4 prices for one app + Postgres.

Go further on Hubfly space

• Move an existing app over: follow How to move your app from Railway to Hubfly space, step by step, including copying your Postgres data.
• Run your whole stack in one place: deploy a docker-compose.yml as-is with web, Postgres and Redis on private networking.
• Price your own app: use the two rates on the Hubfly space pricing page ($0.004 per vCPU-hour, $0.002 per GB-hour) with the formula above. Storage is $0.011 per GB-month on the Standard tier.

Price your app on Hubfly space: start free on the shared tier (360 hours a month, no card), then switch a container to dedicated when it needs to stay on.