Benchtested

Method

How we verify

A guide is only published after its Compose stack has been started and measured. This page describes exactly what that run does — and what it leaves out.

Before publication

  1. Find a deployable app. Projects come from GitHub Trending and Hacker News. A filter reads the project's own documentation and keeps only services you can actually run on a server — libraries, CLIs and agent plugins are discarded.
  2. Draft from the project's documentation. An LLM writes the guide from the upstream README, including the image tag, ports, volumes and environment variables the project documents. Where the project publishes no memory requirement, the guide says so rather than inventing a figure.
  3. Run the stack. The generated Compose file is validated, its images pulled, and the stack started. We wait for containers to reach running or healthy, measure memory, read the published ports, and send an HTTP request to each. The stack is then destroyed along with its volumes.
  4. Record the result, then review. A passing run writes its measurements into the guide. A failing run writes the observed error and the guide is not published as working. A person approves every guide before it goes live.

What the numbers mean

Peak RAM

The highest resident memory reported by docker stats across the stack's containers, sampled once the stack was up. Measured at idle — no monitors, users or load were added.

Startup

Wall-clock time for the whole verification run: validate, pull, start, wait for health, measure, probe. Each guide states whether the image was downloaded or already cached, because that changes the number a lot.

Port

Host ports the stack actually published, read back from Docker rather than copied from the Compose file. This is the port you would open in your firewall.

HTTP

The status code returned by a request to the published port. A 200 means the service answered; 401 or 403 also count as up, since an auth wall is still a running service.

What this does not tell you

  • It is not a load test. Memory is measured at idle. An app that fits in 150 MB empty may need far more once you add data, users or background jobs.
  • It is one host, one architecture. Image availability and memory use differ across CPU architectures and Docker versions. Your result can differ from ours.
  • It is a point in time. We verify the image tag the guide names, on the day we ran it. We do not re-run guides when upstream releases a new version.
  • It covers starting, not operating. Backups, upgrades, reverse-proxy configuration and long-term stability are described from documentation, not measured.

Corrections

If a guide does not work on your server, the measurements above are the place to start comparing. Guides are AI-assisted drafts reviewed by a human, and errors are possible — the upstream project's documentation is always the authority.