Methodology

Every verdict on this site is mechanical. This page is the rulebook, rendered from the same code the build runs — if a badge feels wrong, the argument is with a rule below, not with a label someone typed.

The setup tier

Each project declares seven countable facts (tierFactors): how many containers it runs excluding the shared reverse proxy, whether it needs an external database, outbound mail, an OAuth registration, a DNS record, a GPU, and how many secrets the installer must generate. The tier is derived by the first matching rule, in order:

  1. ONGOING OPS if the app needs a GPU (needsGpu === true)

    A GPU means driver versions, a container runtime that agrees with them, and hardware you keep matched as both move. That is a standing commitment, not an install.

  2. ONGOING OPS if five or more containers (containers >= 5)

    Five or more services is a stack. On any given morning one of them is unhappy, and you are the only person who is going to notice.

  3. ONGOING OPS if a database, mail, and an identity provider — all three (externalDb && needsSmtp && needsOauth)

    A database you back up, mail that has to actually land in inboxes, and an identity integration that breaks when the provider rotates something. Three separate on-call surfaces bolted to one app.

  4. ONE WEEKEND if four containers (containers >= 4)

    Four services still fits in a weekend, but part of that weekend is spent reading logs to work out which of the four is the one that is wrong.

  5. ONE WEEKEND if a database plus one outside integration (externalDb && (needsSmtp || needsOauth))

    A database and an outside service fail in completely different ways, and you have to learn both failure modes before you trust the thing with real data. Budget the second day for whichever one surprises you.

  6. ONE WEEKEND if six or more secrets to generate (secretsToGenerate >= 6)

    Six generated secrets is a configuration surface where one transposed character costs an hour, and the error message will not be about the transposed character.

  7. ONE COMMAND if one container, no database, no outside integration, at most one secret (containers <= 1 && !externalDb && !needsSmtp && !needsOauth && secretsToGenerate <= 1)

    Nothing to negotiate with anyone else, nothing to back up separately, at most one secret to generate. This is the case where the compose file honestly is the whole install.

  8. ONE EVENING if up to three containers and at most one outside integration (containers <= 3 && (needsSmtp ? 1 : 0) + (needsOauth ? 1 : 0) <= 1)

    You will type more than one command and read a page of documentation, and it will be running before you go to bed.

  9. ONE WEEKEND if everything else (true)

    Whatever the rules above did not catch has enough moving parts that promising you an evening would be a lie. Set aside a weekend.

Time bands

timeToRunningMin is the budget to set aside — through the first backup — not a stopwatch to the first screen. The build rejects a number outside its tier's band:

Two kinds of “verified”

Tested by us means the install ran end-to-end on a clean, disposable server by our harness, and the stamp carries the date, version, and host. Reported working by readers is exactly that — self-reported, rate-limited, never faked, and never dressed up as more than it is. A page that fails a re-test is downgraded to pending at the next nightly build: out of the sitemap, visibly labelled, never silently stale. Nothing on this site can self-certify — verification state lives outside the contributable data on purpose.

Provenance

Every compose.yml, Caddy block, and install script is authored by us from the upstream documentation, with the source URL recorded per artifact — never pasted from a repository. Prices cite the vendor's own pricing page with the date we read it. awesome-selfhosted (CC-BY-SA) is a lead list, not a source. Drafts are AI-assisted; nothing earns a stamp a test didn't produce.

Credit

The question-shaped format is inspired by canivibecodeit.com — a different site by a different operator, asking a different question: theirs is whether AI can build you a replacement; ours is how you run the real thing.