You Can Calculate Your Maximum Hosting Bill in Advance

The thing people actually fear about usage-based hosting isn't the price, it's the unbounded part — a traffic spike, a runaway loop, or a scraper hammering your endpoint turning a $5 month into something you have to email support about. That failure mode doesn't exist here, because billing follows what you allocate, not what your app consumes. Your CPU and RAM presets determine the charge whether the app is flat out or idle, and since your account has a ceiling on what it can allocate at all, your worst-case monthly bill is a number you can work out today.

Allocated, not consumed#

The distinction is the whole point, so it's worth being exact.

Metered billing charges for what your app actually uses — CPU-seconds burned, gigabytes transferred, requests served. Predictable when traffic is predictable, and unbounded when it isn't. Costs move when your users do.

Allocation billing charges for what you reserved. You picked 0.5 vCPU and 0.5 GB; that's the charge, busy or idle. A viral day costs the same as a quiet one.

Here, the charge is computed from the resource totals across your applications — the same figures shown on the Limits page — priced per minute at the published resource rates. So the inputs to your bill are entirely under your control, and none of them are "how popular were you this week."

The trade is real and worth stating: you pay for headroom you didn't use. If your app is idle 95% of the time, metered billing would be cheaper. What you're buying is a bill that can't surprise you.

Working out your ceiling#

Because allocation is capped by your account limits, there's a maximum. At the default limits — 1 vCPU, 2 GB RAM, 5 GB disk — with the full allocation billed at the published rates:

At default account limits, using the full 1 vCPU, 2 GB RAM, and 5 GB disk for a month totals $7.05. A smaller allocation or shorter runtime costs less; there is no free allowance to subtract.

Raising your account limits or changes to the published rates can move that ceiling.

Check the current rates before relying on the figures — they're published and they can change. The structure is the durable part.

What doesn't change your bill#

• Traffic. Requests, messages handled, gateway events — none of it is metered.
• Number of apps. Usage is aggregated across applications; splitting one app into three costs the same if the total allocation is the same. That's why sizing a staging bot separately.
• How hard your app works. A CPU-bound loop and an idle process on the same preset cost the same.

The one thing that can creep#

Disk. CPU and RAM only change when you change a preset — deliberate, visible actions. Disk changes when your app writes, which happens without you doing anything.

A log file that never rotates, backups accumulating in a volume, cached media — these grow quietly, and unlike CPU they aren't bounded by a preset you chose. Worse, disk has a failure mode the others don't: exceed the account limit and every app in the account stops until you get back under it.

So the one number worth glancing at occasionally is the disk gauge, and the one habit worth having is bounding whatever your app writes — rotate logs, prune old dumps.

Note that stopping an app frees its CPU and RAM but not its disk, since volumes belong to the app rather than the container.

Keeping the bill small#

For a small bot or side project, keep the allocation close to what it needs:

• Start small. A 0.25 vCPU, 0.25 GB RAM, and 1 GB disk allocation costs $1.21 for a full month.
• Don't over-allocate "to be safe." Unused headroom is a recurring charge for capacity you never touch, and it's a common way a small project's bill grows.
• Keep disk small. Prune what you write.
• Stop what you're not using to free allocation for something you are.

FAQ#

Can I get a surprise hosting bill?#

Not from traffic. Billing follows the CPU, RAM, and disk you allocate rather than what your app consumes, so a spike doesn't change the charge.

How do I calculate my maximum bill?#

Multiply your account's allocation limits by the published resource rates and add them. At default limits, a full month is $7.05.

Does running more apps cost more?#

No. Usage is aggregated across all applications, so the total allocation determines the price, not the number of apps.

What can increase my bill unexpectedly?#

Disk, because it grows as your app writes. CPU and RAM only change when you change a preset.

Does a busy app cost more than an idle one?#

No, if they're on the same preset. You're paying for the reservation, not the work.

Is allocation billing always cheaper?#

No. If your workload is genuinely bursty and idle most of the time, metered billing can cost less. You're trading some efficiency for a bill that can't run away.

Wrapping up#

Predictability and efficiency pull in opposite directions, and platforms pick a side. Metered billing optimises for paying only for what you use, and accepts that you can't know the number in advance. Allocation billing optimises for knowing the number, and accepts that you'll pay for a little headroom. For a bot or a side project — where the nightmare isn't a $3 bill but a $300 one you didn't see coming — knowing the ceiling is usually worth more than shaving the average.