New dataset reveals real idle resource usage for self-hosted apps

SelfHost Atlas has published a new open dataset that provides measured resource consumption for hundreds of self-hostable applications. Released in October 2026, this collection records the actual idle memory and disk footprint of software installed on clean, fresh servers using official documentation. The data offers a reality check for developers and system administrators who need to size infrastructure based on observed behavior rather than theoretical minimums.

What happened

The dataset, hosted on GitHub under a CC BY 4.0 license, contains records for 256 applications. Each entry represents a verified installation run where the project’s published install instructions were executed end-to-end on a throwaway cloud virtual machine. The process captures whether the installation succeeded, which operating system was used, and the date of the verification. Crucially, it also records the resource usage immediately after the first boot, providing a baseline for what these applications consume when they are not under load.

The methodology relies on a strict harness that prunes all containers, volumes, and build caches between each test. This ensures that the disk and memory figures belong exclusively to the application being tested, without contamination from previous runs. The measurements include the sum of memory reported by Docker stats for all running containers thirty seconds after startup, as well as the total disk space used by images, containers, and volumes. These figures are paired with metadata about the specific machine configuration used for the test, such as the instance type and OS version.

A significant aspect of this release is the distinction between measured values and documented recommendations. The dataset includes both the observed idle RAM and the minimum RAM suggested by the upstream project or the atlas editors. In many cases, these numbers differ substantially. For example, some password managers document a need for 256 MB of RAM but actually idle at just 7 MB. Conversely, photo management tools might recommend 2 GB but idle at roughly 100 MB. This discrepancy highlights the gap between conservative safety margins and actual operational costs.

Key details

• The dataset includes 256 records, available in both JSON and CSV formats, with a DOI for citation.
• Measurements capture idle RAM and disk usage on a pruned, fresh server immediately after installation.
• Install verification confirms that official documentation works on specific OS versions, recording success or failure.
• Documented minimum RAM is clearly separated from measured idle RAM to prevent confusion between recommendations and observations.
• CPU usage, installation time, and maintenance effort are not included in this initial release.
• Data is licensed under CC BY 4.0, requiring attribution to SelfHost Atlas if used or adapted.

Background

When planning infrastructure for self-hosted software, engineers often rely on the minimum system requirements listed in project documentation. These figures are typically conservative, designed to ensure the software runs even on constrained hardware or under unexpected load spikes. However, for small teams or individuals running multiple services on a single virtual private server, these conservative estimates can lead to over-provisioning and unnecessary cost. Understanding the difference between a recommended minimum and actual idle usage is critical for efficient capacity planning.

Self-hosting involves running software on your own infrastructure rather than relying on a third-party SaaS provider. This gives users control over their data and customization options but shifts the burden of maintenance and resource management to the user. Tools like Docker simplify deployment, but they do not eliminate the need to understand how much memory and storage each container consumes. Without accurate data, administrators may allocate too much resource to one app, starving others, or pay for larger server instances than necessary.

Why it matters

For teams managing their own software stack, accurate resource data directly impacts budget and performance. If an administrator assumes every app needs the documented minimum RAM, they might provision a server with 8 GB of memory when 4 GB would suffice based on actual idle measurements. This over-provisioning increases monthly cloud bills without adding value. Conversely, knowing the true idle footprint allows for tighter packing of services on a single host, maximizing the utility of existing hardware.

The dataset also serves as a verification layer for installation documentation. In the fast-moving world of open source, install instructions can become outdated quickly. By recording which OS versions successfully ran the install scripts on specific dates, the dataset helps users identify which combinations are known to work. This reduces the time spent troubleshooting broken dependencies or incompatible system libraries during initial setup. It provides a baseline of confidence that the software can be deployed as described.

Furthermore, the transparency of the methodology builds trust. Because the data is generated by an automated script on clean machines, it removes human bias or optimization tricks that might skew results. Users can see exactly how the numbers were derived, including the specific Docker commands and system states. This level of detail allows DevOps engineers to replicate the tests in their own environments if needed, ensuring the data aligns with their specific use cases and constraints.

What you can do

• Download the CSV or JSON files from the GitHub repository to analyze resource usage for apps you currently run or plan to deploy.
• Filter records by install_verified_date to ensure you are looking at recent tests, as older installs may not reflect current software versions.
• Compare documented_min_ram_mb with measured_ram_mb for your target applications to identify potential over-provisioning in your current setup.
• Use the install_verified_os field to check if the application has been tested on the same operating system version you use in production.
• Attribute the data properly using the provided CC BY 4.0 guidelines if you publish any analysis or dashboards based on this dataset.
• Monitor the repository for updates, as the dataset is regenerated monthly to include new applications and refreshed measurements.