Dora NodaOn September 1, Render changed the deal for background work. Task runs on Render Workflows moved to a new default flex compute plan: up to 1 CPU and 4 GB of RAM, billed only for the CPU and RAM each run actually consumes, prorated by the second. The old starter and standard plans are gone, and every task that used them now runs on flex automatically.
This strikes at the exact spot where the flat-box argument was weakest. A Hetzner CX22 at about €5.49 a month (roughly $6 after 2026's repricing rounds) is unbeatable for work that keeps the machine busy. But sparse, computationally cheap task runs — the nightly report, the hourly sync, the webhook handler that fires eleven times a day — leave owned capacity idle between invocations while the meter keeps running at full flat rate. Usage billing flips that: you pay for seconds of execution, not hours of idleness.
So let's do the thing nobody else will do for you: price three realistic workload mixes both ways, find the crossover points, and name the variable that actually decides the bill. Spoiler: it isn't peak task size. It's frequency.
What changed on September 1
Before diving into the numbers, here is the flex rate card, straight from Render's docs:
| Resource | Flex rate | How it's measured |
|---|---|---|
| CPU | $0.20 per CPU-hour | Cumulative virtual CPU time over the run's full duration |
| RAM | $0.05 per GB-hour | Sampled multiple times per second |
A run that constantly pins the whole plan (1 CPU, 4 GB) bills at the maximum $0.40 per hour. But most background tasks don't look like that. Render's own examples tell the story: a light task averaging 0.1 CPU and 0.2 GB costs $0.03 per execution-hour, and a mid-size task at 1 CPU and 1 GB costs $0.25 per hour. Billing is prorated by the second, with a minimum charge equivalent to one second at 0.1 CPU and 0.1 GB of RAM — a fraction of a cent per run, negligible in every scenario below.
Two structural details matter for the comparison. First, each task run spins up its own instance and Render deprovisions it when the run completes, with automatic retries per your settings and queuing at no extra charge. You get managed execution semantics — retries, isolation, per-run observability — bundled into the metered price. Second, task state (inputs and return values, kept 30 days for retries and debugging) bills separately at $0.25 per GB per month, and Workflows has no native scheduling: timed runs need a cron job trigger, and each cron schedule carries Render's $1-per-month minimum. Those extras are small, but an honest comparison includes them, and Section 4 does.
For the flat-box side, the reference is a Hetzner CX22 — 2 shared vCPUs, 4 GB of RAM, 40 GB of disk — at about €5.49 a month after the April and June 2026 repricing rounds, roughly $6 depending on region, VAT, and the exchange rate. It runs 24/7 whether your jobs need it or not, and it can host your web service and database alongside the workers, which turns out to be the most important sentence in this post.
Three workload mixes, priced both ways
Here are three mixes a real team would recognize, each priced as flex compute plus its cron schedulers versus the flat box. All flex rates follow the $0.20/CPU-hour plus $0.05/GB-hour formula.
Mix 1: the sparse cron mix. A nightly report (5 minutes at 0.3 CPU and 0.5 GB), an hourly sync (30 seconds at 0.1 CPU and 0.2 GB), and occasional webhook-triggered bursts (about 1.5 execution-hours a month at 0.2 CPU and 0.3 GB). Total: roughly 10 execution-hours a month.
Mix 2: the typical small-team mix. A polling job every 5 minutes (10 seconds a run at 0.1 CPU and 0.2 GB — 24 execution-hours a month), a daily 20-minute ETL (10 execution-hours at 0.6 CPU and 1.5 GB), plus deploy-triggered tasks (2 execution-hours at 0.4 CPU and 1 GB). Total: roughly 36 execution-hours a month.
Mix 3: the busy queue worker. One queue consumer running about 12 hours a day at 0.4 CPU and 1 GB — 360 execution-hours a month of sustained, always-something-to-do work.
| Mix 1: sparse cron | Mix 2: team mix | Mix 3: busy worker | |
|---|---|---|---|
| Monthly execution-hours | ~10 | ~36 | ~360 |
| Flex compute | ~$0.47 | ~$2.93 | ~$46.80 |
| Cron schedulers ($1 each) | +$2.00 | +$2.00 | $0 (event-driven) |
| Flex all-in | ~$2.47 | ~$4.93 | ~$46.80 |
| Flat CX22 box | ~$6.00 | ~$6.00 | ~$6.00 |
| Winner | Flex, 2.4x cheaper | Flex, narrowly | Box, 7.8x cheaper |
Read the shape of that table, not just the cells. At 10 execution-hours a month, flex wins even after paying for two cron schedulers — the schedulers cost more than the compute. At 36 hours, it's nearly a tie on raw dollars. At 360 hours, usage billing is a blowout loss: $46.80 for what a $6 box absorbs without noticing. Render's own answer to Mix 3 would be an always-on starter worker in the ~$7-a-month tier rather than metered task runs, which tells you the product boundary Render itself draws: flex is for intermittent work, not for saturated workers.
The crossover rule: frequency decides the bill
The three mixes suggest a general rule, and the math is simple enough to carry in your head. The flat box wins once your monthly execution-hours times your average flex rate exceed the box price:
box wins when (execution-hours per month) × (average /hour) > ~\6
Run that at the three flex rates teams actually see:
| Average task profile | Flex rate | Breakeven vs. the $6 box |
|---|---|---|
| Light (0.1 CPU, 0.2 GB) | ~$0.03/hr | ~200 execution-hours/month |
| Medium (0.5 CPU, 1 GB) | ~$0.15/hr | ~40 execution-hours/month |
| Maxed (1 CPU, 4 GB) | $0.40/hr | ~15 execution-hours/month |
Two hundred light-task hours a month sounds like a lot until you convert it: that's about 6.7 execution-hours a day, or one light task running 17 minutes out of every hour, around the clock. A surprising number of side projects and early-stage products sit well under that line.
At the other end, 15 maxed-out hours a month is one heavy task running 30 minutes a day — past that, you should never have been on metered billing. But the sensitivity that matters most isn't task size, it's frequency growth. Task runs scale with events: more users means more webhooks, more rows means longer ETLs, more deploys means more triggered tasks. A mix that costs $2.47 today can cost $25 in a year without any single task getting bigger — just more of them, more often. The flat box, meanwhile, costs $6 at every point on that curve until you saturate the machine. So the real question isn't "which is cheaper for my current mix" but "where on the frequency curve will I be in twelve months, and how will I know when I've crossed over?" If you can't answer the second half — if nothing alerts you when execution-hours cross the breakeven — usage billing's low entry price becomes a slow leak you'll discover in an invoice, not a dashboard.
The honest ledger on both sides
So far this has been a compute-price shootout, and compute price is never the whole bill. Here's the rest of the ledger, both columns.
What flex really costs beyond the rate card. Task-state retention at $0.25 per GB per month is genuinely tiny — 200 MB of retained inputs and return values costs five cents — but it scales with payload size and run count, so chatty tasks with large return values deserve a glance. The cron-scheduler minimums are the bigger gotcha: at $1 per schedule per month, a team with six cron-triggered workflows pays $6 before running a single second of compute, which wipes out flex's advantage on the sparsest mixes. Consolidate schedules where you can — one cron trigger fanning out to multiple tasks beats six lonely schedules.
And the per-run minimum charge, while negligible per run, is a reminder that flex meters runs, not outcomes: a retry storm from a failing dependency bills five times for zero completed work, so retry budgets and alerting are cost controls, not just reliability controls.
What the box really costs beyond €5.49. The box has no built-in retries, no managed queueing, no per-run isolation, and no deprovisioning — every one of those is something you build, configure, or accept the absence of. A stuck worker on your box holds its process slot until you notice; on flex, the run times out, retries per policy, and shows up in observability. The box is also a single point of failure unless you've built the second machine and the failover, at which point your $6 comparison is really a $12 comparison with your own ops time on top. And idle waste cuts both ways: the box wastes 100% of its capacity between sparse runs, which is precisely the gap flex was built to exploit.
The sentence that reframes everything. If the box already exists — if you're already running web services and a database on owned capacity — the marginal cost of background jobs on it is zero dollars. Not six dollars: zero. The flex-vs-box comparison only prices at $6 when the box would exist solely for background work. The moment the machine is shared infrastructure, usage billing has to beat free, and it can't. This is why the "typical small-team mix" row is nearly tied at $4.93 versus $6.00 and yet most teams on owned hardware would still be irrational to switch: their $6 is already spent.
Which shape wins for you
With the numbers and the ledger in hand, the decision compresses to frequency and context:
- Under ~10 execution-hours a month, no always-on needs: flex wins outright. This is the side project with a nightly job and the prototype with event-triggered tasks. Pay the $1 scheduler minimums and move on.
- 10 to 40 execution-hours, no shared box: flex still wins, but watch the scheduler count and set a billing alert at your breakeven. You're one usage spike from the crossover.
- Over ~40 execution-hours, or any sustained worker: the flat box wins, often by 5 to 8x. Usage billing on a saturated worker is the most expensive way to buy compute in this comparison.
- A box already running web or database workloads: the jobs ride free. Don't pay metered rates for capacity you've already bought.
Zoom out one level and this is a familiar cycle: metered pricing wins sparse workloads, flat pricing wins saturated ones, and every platform eventually offers both because no single shape fits a workload's whole life. Render now has both shapes for background work — flex for the intermittent, always-on workers for the saturated — which mostly moves the decision from "which vendor" to "which meter," a healthier question with a computable answer.
The same logic applies if you run the platform rather than rent it. A self-hosted PaaS has the same two shapes — shared always-on worker capacity and scale-to-zero task execution — and the same frequency curve decides between them. The teams that get this right aren't the ones that pick a side; they're the ones that measure execution-hours per workload and let each job sit on whichever side of the crossover it earns.
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.
