Stack planner

Pick the services you intend to run, say what the host operating system is and how many people will use it, and this returns a memory figure you can buy against, the number of containers you are taking on, and the problems that only appear once the stack is assembled: two services wanting the same port, services that cannot be backed up by copying files, and anything with no arm64 build.

It is for the decision you make before you spend money or commit a machine: is this a 4 GB mini PC or a 16 GB one, does it fit on the Raspberry Pi you already own, and is the thing you are about to add the one that tips the whole box over. It is also useful in reverse, on hardware you already have, to find out which two services on your wishlist are the ones you cannot afford.

Nothing you select leaves your browser. There is no request, no analytics event and no server side to this page: the whole dataset is embedded in the page and the arithmetic runs locally.

How the number is calculated#

Every figure comes from the same dataset that generates the tool profiles, so the planner cannot disagree with a profile page. The steps are:

1. Sum ram_typical_mb for the selected services. That is the observed footprint in ordinary single-household use, or the documented minimum where a project states one.
2. Multiply by a household factor: 1.0 for one person, 1.15 for two to four, 1.35 for five or more. Concurrency costs memory in sessions, transcodes and worker processes, not in a second copy of the application.
3. Add the host operating system: 512 MB for a minimal Linux server, 1024 MB for Debian or Ubuntu with Docker, 2048 MB for a Proxmox host, 3072 MB for TrueNAS, which includes the ZFS ARC that will otherwise surprise you.
4. Multiply by the headroom factor you chose, 1.15, 1.3 or 1.6.
5. Round up to the next size RAM is sold in: 2, 4, 8, 16, 32, 64 or 128 GB.

The "show the arithmetic" panel prints every intermediate value. A calculator that will not show its working is asking you to trust a number that came from nowhere.

Operational load is summed separately and flagged above 18, port collisions are read from each service's default ports, and services whose datastore implies a database dump are listed rather than silently included.

What this deliberately does not model#

• Peaks. An Immich first import will saturate every core for hours and hold machine learning models resident. A transcode is a spike, not a baseline. Size for the ordinary evening, then keep the headroom for the bad one.
• CPU, GPU and disk. A stack that fits in RAM can still be unusable on a two-core N-series chip with a spinning disk. Transcoding and local models are decided by the GPU, not by memory.
• Anything you configure differently. Move Home Assistant recorder to MariaDB, or point Paperless-ngx at an external Postgres, and both the memory and the container count change.
• Virtualization overhead. If these run in VMs on Proxmox VE, each guest carries its own kernel and its own headroom, and the totals climb by roughly 512 MB per guest.
• One machine. The planner assumes a single host. Splitting the stack is often the right answer and the tool will not suggest it for you.

What to do with the answer#

Buy the purchase figure, not the provisioned one. Then take the two warnings seriously: run the Port conflict checker before you write any compose files, because remapping a port later means touching every bookmark and every client, and run the Backup planner on the same selection to see which services need a dump before a snapshot. If the operational load total came back above 18, drop something now rather than in year two, and read Choosing home server hardware before you order anything.