How Much Server Does Your App Actually Need?

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

Nobody knows, so everybody guesses upward. The first deploy gets four cores and eight gigabytes because that sounds safe, and it runs at three per cent of both for a year.

Guessing upward is not free. You pay for it monthly, and worse, you learn nothing: an application with ten times the headroom it needs never tells you where its limits are, so the day something changes you are still guessing — just with a bigger bill.

The honest starting point is that a small web application is usually memory-bound and almost never CPU-bound, and that the two run out in completely different ways.

Memory is a wall, processor is a queue

Run out of processor and things get slow. Requests queue, latency rises, and the system keeps working badly — which is unpleasant, and recoverable, and visible in a graph before it becomes an outage.

Run out of memory and the kernel kills something. There is no degraded mode. The process is gone, the requests it was serving are gone, and whatever it had not written down is gone with it.

That asymmetry is why memory decides how much fits on a machine and processor mostly does not — and why a queue is rarely the first thing you need: another container is more memory, permanently. Processor can be oversubscribed safely because workloads take turns; memory cannot, because nobody gives it back on request.

So size the memory for the peak you can actually reach, and treat processor as the thing you tune afterwards.

Measure the shape, not the average

Average usage is the least useful number. A process sitting at 200 MB and briefly touching 900 MB while it builds a report needs the 900, and an average will tell you 220.

Three things to look at instead:

• The peak under real work, not idle. Import a real file, render the biggest report, run the job that takes longest.
• Whether it comes back down. Memory that rises and stays is a leak or an unbounded cache, and no amount of headroom fixes it — it just moves the crash further out.
• What happens at startup. Some runtimes allocate far more in the first seconds than they ever need afterwards, and a container sized for the steady state dies before reaching it.

If you cannot get these from production, get them from the machine you already have. A laptop running the same container tells you more about shape than any calculator.

Start small enough to learn something

Deploy at a size you expect to be a little tight, watch, and move up once. That is faster than starting large, because a small instance produces evidence and a large one produces silence.

What makes this safe is the ability to change it without ceremony. If resizing means a migration, people over-provision — rationally. If it means redeploying at a different size, they can afford to be curious.

Watch what the plan itself counts, too. A limit that counts your containers rather than your projects prices the shape of your architecture instead of the work it does, and it will push you toward a smaller size than the workload wants.

The other half is knowing what a size actually buys. A class named for a number of cores tells you nothing about whether it shares a machine, whether the memory is guaranteed or burstable, and what happens when a neighbour is busy. Those are the questions that decide whether the numbers mean anything — the same kind of unglamorous operational question as where your secrets live, and just as easy to defer past the point where it is cheap.

FAQ

What size should a small web app start at? Half a core and 512 MB carries a great many of them. If that is wrong you will know within a day, which is the point of starting there.

Is it cheaper to run one big instance or several small ones? Usually several small ones, because you can size each to its own shape. One instance holding two workloads is sized for the sum of their peaks.

How do I know if I am CPU-bound? You are usually not. Check whether latency rises while processor sits low — that is almost always waiting on a database, a network call, or a lock.

Does an AI-built app need more? No, but it is more likely to be sized carelessly, because the person deploying it has not watched it run. On aidrop.it the classes are fixed sizes rather than sliders, and the plan's memory is a single pot spent across everything a team runs, so an over-provisioned project is visibly taking room from the next one.

What about autoscaling? It solves a problem most small products do not have, and it hides the one they do: an application that grows without bound scales up rather than being fixed.

Cover: https://unsplash.com/photos/wTtBtw80erg by josh A. D. on Unsplash. Alt text: A hand holding an extended tape measure against a plain grey background.