The state of self-hosting in 2026

Two things happened to self-hosting at once, and they pull in opposite directions. The hardware problem got solved: across 105 profiled tools the median idles at 150 MB, 61 of them run as a single container, and 95.2 percent ship official arm64 builds. A 200 dollar mini PC now runs a stack that needed a rack in 2016.

The other thing is that the bill did not disappear, it moved. It moved into upgrade discipline, into identity, into the fact that 81.9 percent of these tools cannot be safely backed up by copying files while they run, and into a licence layer where 7.6 percent of the index is no longer open source in the OSI sense. None of that shows up in a RAM figure, which is why the RAM figure is the least useful number on this page.

The hardware barrier collapsed and nobody updated the advice#

The spread is what matters, not the median. Idle memory across the index runs from 15 MB at the bottom to 8192 MB at the top, with the 90th percentile at 900 MB. That means nine out of ten tools here fit inside a gigabyte, and the distribution is not remotely normal: it is a dense cluster under 300 MB with a handful of appliances sitting several thousand MB out on their own.

31.4 percent need more than one container. The rest are one process, one volume, one port. If your mental model of self-hosting still involves a database server per app, the index says otherwise.

The operational load distribution has the same shape. 63 tools score 1 or 2, which is 60.0 percent, and the mean is 2.4. The mode is 2: one or two services, occasional config edits, upgrades that usually apply cleanly.

The tail is the story. 14 tools score 4 or 5, which is 13.3 percent of the index, and exactly one scores a 5 (Wazuh, which is a SIEM with an OpenSearch indexer underneath and is a full-time system in a way nothing else here is). That tail is not randomly distributed. It is identity providers, mail servers, orchestrators, git forges and the tools that hold everyone else's data: authentik, Keycloak, GitLab CE, Harbor, Nextcloud and Proxmox VE. In other words, the infrastructure that everything else depends on is also the infrastructure that costs the most attention, which is exactly the wrong way round for a person doing this in evenings.

The practical reading: you can run twenty tools from the 1 and 2 bands and barely notice them. Adding one tool from the 4 band changes what your weekends look like.

Where the memory actually goes#

These are category means, and every high bar is a mean dragged by one outlier rather than a category that is uniformly expensive.

• Platform is top because it contains whole operating systems. TrueNAS at 8192 MB and Proxmox VE at 2048 MB are not leaking memory, they are ZFS ARC and a hypervisor doing their jobs. Podman in the same category idles at 40 MB.
• Security looks alarming entirely because of Wazuh at 6144 MB. Take it out and the category is CrowdSec at 120 MB and Fail2ban at 40 MB.
• Developer is GitLab CE at 4096 MB and Harbor at 2500 MB against Gitea and Forgejo at 150 MB each. Two forges doing the same job, twenty seven times the memory.
• Networking and monitoring sit at the bottom and stay there. There is no outlier hiding in them.

Read the chart as "does this category contain a monster", not as a budget per category. A stack of a proxy, a DNS blocker, a media server and a photo app is nowhere near these averages.

Almost every tool in that table also scores 1 for operational load. The correlation is causal: things that hold no relational state are both small and boring to run. Dozzle stores nothing at all, Caddy stores certificates, Gatus and Glance are configured entirely in YAML you keep in git.

Compare the two tables and one thing should look wrong. Unraid idles at 2048 MB and scores 2 for operational load. TrueNAS idles at 8192 MB and scores 3. Meanwhile Authelia idles at 35 MB and scores 3, and Miniflux idles at 40 MB and scores 3.

Memory and attention are different axes. Buying a bigger stick of RAM fixes one of them.

The real cost is upgrade discipline#

Every entry in that table earns its score with a specific, documented, upgrade-shaped hazard, and they are worth reading as a set because the pattern repeats:

• Nextcloud ships three majors a year, supports each for twelve months, and its admin manual is explicit that you cannot skip one. An instance on 31 reaches 34 by going through 32 and 33, each with its own migration run and its own PHP version window. Staying supported means two or three upgrade windows a year, forever.
• Immich removed pgvecto.rs in v3.0.0. If your instance predates 1.133.0 you must reach a VectorChord-capable version and let the migration finish first, and downgrades are not supported.
• n8n 2.0 blocked environment access in Code nodes by default, disabled ExecuteCommand, and dropped MySQL and MariaDB outright rather than deprecating them. Workflows that worked on Friday fail on Monday with no error you would recognize.
• Grafana 12 removed AngularJS. Community panels that never got a React rewrite render as an error and there is no toggle to put it back.
• authentik 2026.8 started ignoring forwarded headers unless the source network is listed in AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS. Upgrade without setting it and every login appears to come from your reverse proxy, so IP policies stop matching and rate limiting counts everyone as one client.
• Uptime Kuma rewrites heartbeat history on the v1 to v2 upgrade in a one way migration that must not be interrupted.

None of those is a bug. Each is the right decision for the project and a cost transferred to you. The honest version of "self-hosting is cheap now" is that the hardware is cheap and the reading is not optional. An update strategy that does not lose data is the discipline that makes this survivable, and pinning exact tags rather than latest is the single highest-value habit in the list.

81.9 percent of these tools cannot be copied while running#

86 of 105 tools need a database dump or a stopped container before their data is restorable. Only 19 are safe to copy live, and that list is mostly proxies, caches and model runners with almost nothing to lose: Caddy, Traefik, Ollama, rclone.

This failure stays invisible until the day it matters. A cp -a of a live Postgres data directory produces something that looks complete, restores without complaint, and is inconsistent. Seafile's own manual specifies the order (dump SQL first, copy the data directory second) so that every database row points at an object that already exists. PLANKA ships a backup script whose header states plainly that anything created between the dump and the file copy leaves an orphan.

If you have never restored from your backups, you do not have backups. Backups that actually restore covers the rehearsal, Backing up a running database covers the per-engine commands, and The backup blind spot has the full breakdown by datastore.

Identity is the other half of the invisible bill#

90 tools in the index have user accounts. 45 of those, 50.0 percent, speak OIDC natively. That is a genuine improvement on where this stood three years ago, and it is also the ceiling: 28 tools, 31.1 percent, support no external identity at all.

The local-accounts-only list is not a list of obscure projects. It includes Plex, Sonarr, Radarr, Prowlarr, Pi-hole, AdGuard Home, Uptime Kuma and Syncthing. Every one of those is a separate password in a household where you were trying to have one. The workaround is a forward-auth proxy in front, which works and is one more thing to run. The single sign-on gap and Single sign-on for self-hosters deal with what that actually costs.

The licence layer got complicated#

44.8 percent of the index is copyleft, the largest block is permissive MIT and Apache-2.0, and 7.6 percent is source-available or proprietary. On its own that last figure looks negligible.

It is not, for two reasons. First, 8 tools is a count of where projects have landed, not of where they are heading, and several of them arrived there recently by changing terms rather than by starting that way. Second, the pattern in those changes is consistent: the feature that makes a tool usable by more than one person, most often single sign-on, is the feature that moves to the paid edition. Licence drift works through the specific cases with the licence text for each.

How to read this index, and what it is not#

This is a structured survey, not a census, and the difference matters for anything you conclude from it.

• The 105 tools were chosen for search demand and real-world use, not sampled randomly from a registry. Popular tools are overrepresented on purpose, because the index exists to help someone choose. Do not read "44.8 percent copyleft" as a statement about self-hosted software in general.
• Memory figures are single-household observations, not benchmarks. They describe a small single-user install at idle, measured once, not a load test. Where a project publishes an official minimum, that figure is preferred and the profile says so. Treat them as an order of magnitude for planning, not as a spec you can hold anyone to.
• The operational load score is an editorial judgement, applied against a published rubric and explained per tool. Two careful people would disagree on some entries by a point. The rubric is on our methodology; if a score looks wrong to you, the reasoning is on the profile and you can argue with it.
• Ports, licences and version facts are checked against primary sources, meaning LICENSE files, official documentation and release notes, and every profile lists them.
• It is a snapshot. Archived projects, licence changes and edition splits happen between updates.

The full dataset is published as JSON and CSV under CC BY 4.0, so you can check any figure on this page yourself, or run the analysis differently and disagree with it in public.

What to do next#

If you are planning a stack, add up the idle memory column before you buy hardware, then add up the operational load column and be honest about how many 3s and 4s you want in one year. Stack planner does both. If you are already running things, the two highest-return audits are a restore test and a check of which of your services still have their own private password list. Your first self-hosted server covers the decisions that are hard to undo, and When not to self-host covers the ones you should not make at all.