The RAM we list for self-hosted apps is about 5× what the median one idles at

copySelfHost Atlas (2026). The RAM we list for self-hosted apps is about 5× what the median one idles at. https://selfhostatlas.com/blog/listed-ram-vs-idle-ram. Data: doi:10.5281/zenodo.22983606

Every app page on this site lists a minimum amount of RAM. For 268 of the 312 apps in our catalog we also measured what the app actually uses once it is installed and idle. The two numbers disagree by a wide margin, and the margin is the interesting part.

#The headline

For each of the 268 apps with both numbers, divide the listed minimum by the measured idle RAM. The median of those ratios is 4.7.

• 228 of the 268 apps (85%) idled below half of their listed minimum.
• 66 idled below a tenth of it.
• Only four used more than listed: PostHog (16,824 MB measured against 16,384 MB listed), Twenty (2,232 MB against 2,048 MB), Tube Archivist (2,095 MB against 2,048 MB) and Jenkins (492 MB against 256 MB).

Idled below half of listed228 appsIdled below a tenth of listed66 appsUsed more than listed4 apps

#What the two numbers are

They answer different questions, which is why they are not in conflict.

• Listed minimum RAM is what the upstream project documents, or our own sizing recommendation where upstream documents none. The values sit on standard instance sizes (256, 512, 1,024, 2,048 MB and so on). It is a recommendation for running the app, not an observation. The dataset does not record which of the two sources a given figure came from, so we cannot attribute the gap to upstream versus our own sizing.
• Measured idle RAM is the memory docker stats reports for every running container of the app, summed, 30 seconds after the install finishes. It is idle, immediately after first boot, on Google Cloud e2 machines. It is never under load and never a peak.

A few examples at the extremes of the same comparison:

#What this does not say

• It does not say upstream documentation is wrong. Minimums are usually meant to leave room for imports, indexing, concurrent users and a grown database; an idle server with an empty database exercises none of that.
• It does not say you can run an app in its idle footprint. Idle memory is a floor. We did not measure usage under load, so we have no figure for how far above idle a busy instance climbs.
• It does not generalise beyond this setup. 262 of the 268 measurements were taken on a Google Cloud e2-standard-2; six apps (PostHog, Sentry, Langfuse, LiteLLM, AppFlowy, RustDesk) were run on an e2-standard-4 or -8. All ran Ubuntu 26.04 LTS with Docker 29.x on a machine pruned of earlier apps; 156 used the same Docker release (29.8.1).

#How to read it

This is not a sizing guide. The listed figure is a recommendation, the idle figure is a floor, and we have no load measurements. Where measured idle exceeds the listed minimum (PostHog, Twenty, Tube Archivist, Jenkins), the listing understated even idle use.

The idle figures come from our install-verification harness, which installs each app from its published snippet; how that works is described on How we test. To turn a stack into a monthly cost, use Build your stack.

#About the numbers

This post uses the install-verification dataset exported on 2026-10-25 (release v1.8.0: 312 records, 268 with both a listed and a measured RAM figure; measurements were taken between 2026-08-28 and 2026-10-25). The dataset is CC BY 4.0 and cited as concept DOI 10.5281/zenodo.22983606, which always resolves to the latest version. Our earlier idle-RAM report used a smaller, older set of apps and reports a different median (168 MB); the two should not be compared directly.