Container Count per Host Calculator

When you turn on your new server and see it booting up containers, it makes you feel accomplished. It’s running a resolver, now Home Assistant, now a Plex helper, now a logging stack. Everything feels under control until you add another service. Your machine grinds to a halt. Your host goes unresponsive, the disk light remains solid, and your UI lags.

Welcome to the world of homelab. Sure, you didn’t fry your hardware, but you’ve used up the resources required to stabilize your virtual environments. You can easily count CPU cores and RAM sticks, and most folks plan their host based off them. Containers don’t care about the specs on the box; they care about what’s available in the moment. Once you plug in your sustained performance numbers into the calculator it does the math for you, no more guessing who’s going to fall over first. It helps you think beyond raw hardware spec and look at actual runtime environment.

How to Plan Your Server Resources

Most people go wrong with the storage layer. That shiny new SSD has five thousand IOPS? You’re not going to get that if you’re running database commits and backups overnight. Instead, you’ll be getting an average over time once wear leveling and cache flushing take effect. And even if all you’ve got are two dozen container spitting out log messages, they’ll start fighting for disk access long before the CPU hits its limit. To account for this, the tool lets you specify a reserve percentage, which isn’t wasted capacity; rather, it’s protection from those times when queuing up requests starts to slow the interface down.

The other big issue is memory. Got a 32-gigabyte instance? Think you can allocate all of it? Nope! There’s filesystem overhead. There’s OS overhead from page caching. If you don’t leave yourself some cushion, the kernel will begin to kill things in order to save its own ass. That’s not a bug; that’s Linux being Linux when it’s under the gun. As the memory usage table (reference) illustrates, your small, simple webhooks app will get by with just a few hundred megabytes; your large database stack will consume many gigs. Know what you’re running and why.

The last bottleneck: Network Ports (Which nobody talks about) Have lots of terabytes of disk? There are cores all over the place. Fine. But what happens when you want to put 10 different services right on the host? Well guess what… port collisions is merciless. They happen instantly.

The calculator treats available ports as a hard cap too (like RAM), and reminds you why a reverse proxy isn’t something you can live without (it’s a capacity multiplier). It is a way to free up your scarce network addresses.

That’s when it gets real: oversubscription. If you’re confident that no service will spike at any given time, just slap a couple of virtual CPU cores on each physical one. That’s fine for automation scripts idling away the night, but not for transcoding videos. You get to tweak this parameter in the calculator, but you’ll need to specify a percentage of headroom as well.

This is headroom for the future. This is for the future update that corrupts its config file and leaves behind a zombie process. This is for the backup job that decides to run at the worst possible moment.

Planning for capacity is about minimizing surprise, not maximizing utilization. An eighty percent full host are a broken host. You need to know you can add another service without poring over all the metrics dashboards. And those numbers on the tool aren’t limits, they’re guardrails. They are guardrails to prevent you from hitting the limits of resource contention. Estimate conservativeley. Add headroom. Verify the performance (IOPS). Add headroom if needed. Repeat until you like the number. Reduce services rather than reserves; a slower but available host is preferable to a fast host that goes down. This isn’t a lab you are building to generate new problems, it’s one you’re using to resolve existing ones. You should of made the headroom obvious and the host will pay you back in uptime.