The Unit a Plan Counts Changes What You Build

From the team behind aidrop.it — one workspace to build, host, and keep changing your code.

Every hosting plan counts something. Projects, apps, sites, services, containers, seats. It looks like a billing detail. It is not — the unit a plan counts is the thing it quietly discourages you from having.

If a plan counts services, and your application plus its database plus its cache is three of them, then a plan sold as "three" holds exactly one properly built application. The customer's response is predictable and bad for everyone: they run the database inside the app container, skip the cache, and put the queue in a table.

The plan did not stop them building badly. It taxed building well.

Two limits, and they answer different questions

A capacity plan really has two numbers, and keeping them apart is the whole design:

How many things you may have. A count. It is cheap to enforce and it is what a customer plans around: can this account hold the new client project?

How much those things may consume. A pot of memory and processor, shared. This is what the machine actually runs out of, and it is the number that decides whether anything fits.

When one unit tries to answer both — a "slot" that means a project and means a container — it answers neither well. The count stops describing how many projects you have and starts describing how many pieces they were assembled from.

The test: does the count change when the architecture does?

Run this on any plan you are evaluating, including one you already pay for. Take an application. Add a database behind it. Add a cache. Did the number the plan counts change?

If it did, the plan is measuring your architecture rather than your workload. Two teams running identical traffic pay differently because one split a component out. Worse, the pricing page is now giving architectural advice — and the advice is "keep it in one process", which is the opposite of what you would tell a colleague.

If it did not, the count is measuring what you have and the pot is measuring what you use. That is the arrangement you want, and it is the one we moved to on aidrop.it after noticing our own plans failed this test.

Reserved is not used

The second thing worth knowing before you size anything: capacity limits almost always count what is reserved, not what is busy.

A stopped application still holds its share. An idle one holds all of it. This surprises people who expect a quota to behave like a meter, and it is deliberate — a page that showed headroom based on live usage would offer you room the next deploy is then refused for.

The practical consequence: freeing capacity means removing or archiving something, not turning it off. If you are near a limit, stopping a container is not the fix.

It is also why sizing for your reachable peak rather than your average matters more here than on a machine you rent whole.

The worksheet: normalise a plan to your workload

Plans are not comparable as advertised, because they count different things. They become comparable in four lines. Write down one real application, then fill this in per host:

Workload            1 application · 1 database · 1 cache

A. Units consumed   ___   (what does the host count, and how many is this?)
B. Units included   ___   (on the plan you would buy)
C. Memory needed    ___   (application + every service, added up)
D. Memory included  ___   (the plan's pot, if it states one)

Fits?               A ≤ B and C ≤ D
Price per fit       plan price ÷ how many of this workload fit

The last line is the number to compare, and it is rarely the one on the pricing page. A host whose plan costs twice as much but holds three of your workload is the cheaper host, and no comparison table will tell you that — because the table compares plans and you are buying capacity for a specific thing.

Two traps the worksheet catches. If A changes when you split a component out, the host is pricing your architecture. If D is blank, the real limit is unstated and you will meet it at a deploy.

FAQ

Does a database count against my project limit? It depends entirely on the host, and it is worth checking before you design. On aidrop.it it does not — a project is one slot however many services run inside it, and the database spends memory and processor from the shared pot instead. Elsewhere a database frequently counts as another unit.

Why is my quota full when nothing is running? Because quotas usually count reserved capacity, not live usage. A stopped container still holds its reservation. Archive or delete it to get the capacity back; stopping it is not enough.

Is a project count or a resource pot the better limit? Neither alone. A count without a pot hides the limit that actually stops you; a pot without a count makes a plan impossible to compare. Good plans state both and keep them independent.

Should I run my database inside the application container to save a slot? No, and if a plan makes that tempting, that is the plan telling on itself. Containers are usually restarted with nothing kept, so anything written inside one disappears — you would be trading a billing unit for permanent data loss.

Cover: https://commons.wikimedia.org/wiki/File:B%26Q_Tape_Measure.jpg by 多多123, CC BY 4.0, via Wikimedia Commons. Cropped to 16:9 within the original frame. Alt text: A retractable steel tape measure extended across a plain background.