How to keep your cloud bill from surprising you

A practical guide to bounding what you spend on a deploy platform: how a prepaid wallet works, why credit that rolls over changes the math, and how to set it up on Ownkube.

Ownkube team | | How-To | 7 min

The surprise cloud bill is a genre of story at this point: a service you forgot about ran all month, or a traffic spike metered against a card, and the invoice showed up after the money was already gone. The fix is not watching a dashboard more carefully. It is putting a ceiling on the spend before anything runs, so the worst case is a number you chose on purpose.

This guide walks through how a prepaid wallet does that, where the usual metered and fixed-instance models leak, and how to set your own limit on Ownkube in a few minutes.

TL;DR

  • Postpaid billing (Railway, Render, most clouds) bills you after the meter runs, so a forgotten service or a spike lands on a card you were not watching.
  • A prepaid wallet flips the order: you load a balance, usage draws it down per minute, and at zero your apps pause with their data kept. The most you can lose is the balance.
  • On Ownkube, your plan loads the wallet each month (Personal loads $5, Team loads $20), and unused credit rolls over and never expires.
  • You still control per-app spend with CPU and memory limits, and you can pick metered or a flat box per deployment.
  • Set it up by picking a plan, setting a top-up ceiling, and putting a limit on each workload.

Why postpaid billing surprises you

Most deploy platforms are postpaid. The meter runs, or the instance exists, and the invoice arrives at the end of the cycle. That model is fine when someone is watching it every day. It bites in three predictable ways.

A metered platform like Railway bills per second for what runs, so a service you spun up for a test and forgot keeps spending until you notice. A fixed-instance platform like Render hides the same problem in a quieter shape: you pay for the instance whether it is busy or idle, so the waste is steady instead of sudden. And any postpaid model exposes you to the spike, where a busy day or a runaway process meters against your card faster than an alert can reach you.

None of these is a pricing bug. They are all the same structural fact: the spend happens first and the bill comes second. If you want the bill to be bounded, you have to change the order.

How a prepaid wallet changes the order

A prepaid wallet puts the money in front of the usage. You keep a balance of credit. Everything you run draws that balance down per minute for what it actually uses. When the balance reaches zero, your apps pause and your data stays put until you add credit or the next monthly load arrives.

The practical consequence is that the most you can spend is the balance you loaded. A forgotten service cannot run up a four-figure bill, because there is no card behind it to charge. It draws down the wallet and then stops. You decide the ceiling once, up front, instead of reconciling it after the fact.

On Ownkube the wallet is the billing model for Ownkube Compute, the managed compute you deploy onto with no cloud account of your own. Two things make the math friendlier than a plain prepaid balance:

First, unused credit rolls over and never expires. Your plan loads credit each month and usage drains it, but whatever you did not spend stays on your balance and the next month loads on top of it. A quiet month is not money burned. This is the part most usage-based platforms get wrong: on a postpaid meter there is nothing to roll over, and on many prepaid systems the credit expires at the cycle boundary. Here the dollar balance persists.

Second, an idle app barely draws the wallet down. Compute meters both CPU and memory on actual per-minute usage, and most personal software sits idle most of the day. The CPU line goes to almost nothing while nothing is happening, so the balance you loaded stretches further than a fixed instance would let it.

One caveat to be straight about: the monthly build-minutes allowance (300 minutes on Personal, 1,500 on Team) resets each month and does not roll over. It is the wallet dollar balance that carries forward, not the build allowance.

Set your ceiling on Ownkube

Here is the setup, start to finish.

1. Pick a plan, which sets the monthly load

The plan is the amount of credit loaded into your wallet each month.

PlanMonthly priceLoads into walletBuild minutes
Personal$5 / month$5 / month300 / month
Team$20 / month$20 / month1,500 / month

Both draw from the same prepaid wallet. Team adds unlimited organizations, shared billing, and priority build capacity. There is no free tier on Compute: the plan load is the floor of what you spend, and it is also credit you get to use.

2. Decide how each app is priced

Metered is the default and fits most apps. You set a CPU limit and a memory limit as ceilings, and the bill follows the meter, not the size you picked. An idle app costs almost nothing on CPU.

If you would rather a workload have a flat, predictable price, put it on a reserved box instead: a fixed-size Spark box (shared CPU, from $5 a month) or Core box (dedicated CPU, from $58 a month) that bills the same rate busy or idle. You choose per deployment and can switch later, so a bursty web app can meter while a steady worker sits on a flat box, in the same project.

Databases and caches are always reserved. A managed Postgres runs on a database box from $4 a month plus storage at $0.15 per GB. A Valkey cache runs on a cache box from $2 a month.

3. Set a per-workload limit

The CPU and memory limits you set on each deployment are the ceilings that cap how fast any single app can draw the wallet down. Set them to what the app actually needs plus headroom. A limit is not a reservation, so on metered pricing you are not billed for the ceiling, only for what the app uses up to it.

# Deploy with explicit resource ceilings via the CLI
okctl deploy --cpu-limit 500m --memory-limit 512Mi

4. Top up on your terms

If usage runs past the loaded credit before the next cycle, you top up the wallet for any amount from a $5 minimum, any time. Because top-ups are something you do on purpose, there is no automatic charge racing ahead of you. The rates behind the meter are about $18 per vCPU per month and $4.50 per GiB per month, which puts a typical always-on app roughly a third under the equivalent Railway bill.

When a fixed box is the safer ceiling

Metered is not always the calmest choice. A workload that runs hot around the clock, like a busy worker that never idles, will meter continuously, and for that shape a flat reserved box gives you a price that never moves. The rule of thumb: meter the things that idle (most web apps and side projects), and reserve the things that run steadily. Since you pick per deployment, you do not have to choose one model for everything.

If predictability across the whole platform matters more than squeezing the idle hours, our comparison of Railway, Render, and Northflank walks through how each billing model behaves at the end of the month.

FAQ

Does prepaid credit on Ownkube expire?

No. Unused wallet credit rolls over to the next month and never expires. The dollar balance persists across cycles, and each monthly plan load adds on top of it. The one thing that resets monthly is the build-minutes allowance, not the wallet balance.

What happens when my balance hits zero?

Your apps pause and your data is kept. Nothing is deleted. Adding credit with a top-up, or the next monthly plan load, resumes them.

Is there a free tier on Ownkube Compute?

No. The Personal plan is $5 a month and loads $5 of credit you then spend, so the plan price is both the floor and usable balance. If you want a genuinely free option, running in your own AWS account on a Starter instance is free (you pay AWS for the instance).

How is this different from Railway’s usage-based billing?

Railway is postpaid: the meter runs and the invoice comes after, and unused amounts do not roll over. Ownkube is prepaid: you load a balance, usage draws it down, and leftover credit carries forward. The ceiling on what you can spend is the balance, not a card.

Can I still get a predictable flat monthly price?

Yes. Put the deployment on a reserved Spark or Core box and it bills a flat rate for as long as it exists, busy or idle. You choose metered or reserved per deployment.

Where Ownkube fits

If the surprise invoice is the thing you actually want gone, the wallet is the answer: you load a balance, usage draws it down, leftover credit rolls over, and the worst case is a number you set. Add per-workload limits and the choice of metered or a flat box, and the spend stays inside lines you drew on purpose. It is built for personal software and small teams who would rather bound the bill than reconcile it. Deploy your first app.

More posts