Method

Every number on this site comes from a recorded run. Each run's raw JSON — every sample, the exact files used, image digests — is linked from the app's page.

The machine

One virtual machine: 4 vCPU, 8 GB RAM, amd64 (x86_64), Linux, Docker Engine with the containerd image store. Every measurement on the site ran on it. The exact kernel and Docker version are in each run's JSON.

Setup

For each app we use its official Docker Compose file, fetched from the upstream project at run time and pinned to a commit or release tag, with default settings and only the environment files the instructions require. The file is used unmodified; its SHA-256 and source link are on the app's page.

What is measured

• Download: the sum of the compressed layer sizes of the linux/amd64 images, read from the registry manifests (each unique layer counted once).
• Images on disk: size of the unpacked images after pull, as reported by docker system df.
• Time to ready: seconds from docker compose up -d to the first HTTP response below 500 from the app's web port.
• Peak RAM: the highest summed memory seen during the first 5 minutes after start (sampled back-to-back, about every 2 seconds).
• Idle RAM and CPU: after a 5-minute settle, 30 samples 10 seconds apart; we publish the median. Memory is what docker stats reports (the container's memory use excluding reclaimable page cache), summed across the app's containers and shown per container too. CPU is docker stats CPU %, where 100% is one full core.
• Disk after first start: size of the app's volumes and bind-mounted data directories at the end of the run.
• Container count, published ports, and the architectures each image offers (from its manifest).

After each run everything is removed (docker compose down -v and the images) before the next one.

Units: memory in MiB (2²⁰ bytes, as docker stats shows it); download and disk in MB and GB (10⁶ and 10⁹ bytes).

When runs happen

A scheduled job checks each app's latest upstream release once an hour and measures at most one app per run: first any app not yet measured, then any app with a release newer than its last run. Old runs are kept as history. A failed run is recorded and shown with its error; it is not retried until it looks good.

Limits

• Idle only: an app with no users, no data and no work to do. Real use — importing photos, transcoding, many users — needs more.
• One architecture (amd64). Numbers on ARM (Raspberry Pi, many NAS) can differ.
• Default configuration only. Enabling features or pointing at external databases changes the picture.
• One machine: memory use can depend on how much RAM and how many CPUs the host has.