Stopped apps now cost you nothing

Hosting has a quiet habit of billing you for things that are not running. The staging copy you spun up in March. The forum you tried for a weekend. The second wiki. Each one is a line item somewhere, or a container idling on resources you paid for, and the rational response is to delete things you might want back. That is a bad trade -- deleting an app to save money means losing its configuration, its domain, its data. As of this week, there is a better one: stop it. A stopped app on Caliber Node costs you nothing.

One pool, not per-app bills

First, the model, because it is the part most hosts get wrong. A subscription here is a pool of CPU, RAM and disk, shared by all of your apps. Nothing is billed per app. Deploying a fifth app costs the same as deploying a first: nothing, as long as it fits in the pool. You size the pool; you decide what runs in it.

That was already true. What changed is what counts against the pool.

Capacity now counts what is running

Stop an app, and its CPU and memory return to the pool instantly -- available to your other apps the moment the stop completes. Not at the end of a billing period, not after a support ticket. Instantly.

What that means in practice: the memory your staging copy was holding is usable by production the moment staging stops. The CPU allowance your weekend project had is your Monday app's to burn on Monday. You are no longer sizing a subscription for the sum of everything you have ever deployed -- you are sizing it for the set of things you actually run at once, which for most people is a much smaller number.

Disk is the deliberate exception. Disk stays reserved for every app that exists, whether it is running or not, because your data is physically stored either way -- a stopped app's database is still a database, sitting on real storage, ready to come back exactly as you left it. Disk returns to the pool only when you delete the app. This is the line between a stopped app and a deleted one, and it is exactly where it should be: stopping costs you nothing and loses you nothing; deleting frees the disk and means it.

The whole model fits in one sentence: running apps use your CPU and memory; existing apps use your disk. If you can hold that sentence, you can predict everything the panel will tell you.

Restarts are honest about what they need

A model like this has one sharp edge, and we chose to make it visible instead of padding it. Starting a stopped app needs its CPU and RAM to be free in the pool at that moment. If you stopped an app, grew another into the space it left, and now want the first one back, the start can fail -- the capacity it needs is in use.

When that happens, the error does not say "insufficient resources" and leave you to guess. It names exactly which running apps are using the capacity, so you know precisely what to stop or shrink to make room. That specificity is the difference between a dead end and a decision: "the pool is full" sends you to a pricing page, while "these two apps are holding the memory" sends you to a choice you can make in ten seconds. The decision stays yours; the information is complete.

The same honesty runs through the rest of the flow:

• The stop confirmation states what a restart will need. Before you stop an app, you see the CPU and RAM it will ask for when it comes back. You are never surprised by a number you saw for the first time at restart.
• The stopped app's page states it too. Come back a month later and the requirement is right there on the page, next to the start button -- no digging through plan details to remember what the app was sized at.
• Nothing is reclaimed behind your back. Stopping is your action, starting is your action, and the pool arithmetic in between is shown, not hidden.

The app library pattern

Here is what this makes possible, and it is the reason we built it. Keep many apps configured in a small subscription, and run the ones you need right now.

Think of it as a library rather than a rack. The analytics tool you check monthly -- stopped twenty-nine days out of thirty, its dashboards and data intact, started when it is time to look. The project management board for a client engagement that ended, kept stopped in case the client returns. A game server that runs on weekends. A tool you evaluated, decided against for now, but configured well enough that deleting it would be a waste. Each of these keeps its disk -- its data, its configuration, its domain -- and none of them takes a byte of RAM or a cycle of CPU while stopped.

Under per-app billing, every one of those would be a monthly charge, and you would delete them. Under a pool that counts only what runs, they are free to keep and cheap to hold -- the only cost is the disk they occupy in a pool you already own. A subscription sized for two or three running apps can comfortably hold a shelf of ten, and you choose which two or three are alive today.

This also changes how it feels to try things. Deploying an app to evaluate it used to carry a small mortgage: it would sit there consuming capacity until you remembered to clean it up. Now the end of an evaluation is a stop, not a delete-and-hope-you-never-need-it-again. The experiment stays on the shelf.

Try it

The pool model is live for every subscription -- there is nothing to enable and no new tier to buy. Stop something you are not using and watch the capacity come back; start it again when you need it, and the panel will tell you plainly whether it fits. If you are new, pick a capacity subscription and start building your shelf. Apps deploy in minutes, with HTTPS, backups, SFTP and a browser terminal included.