Methodology

Short version: every number on this site has a link and a date. If we haven't measured something, we say so.

1. Sources, in order of trust

1. Official documentation from the project itself (docs sites, maintainers' published guidance on GitHub). Quoted closely and linked.
2. Maintainer statements in issues, discussions and forums, marked as such.
3. Community reports from GitHub issues, project forums and Reddit. These are individual data points with different versions, hardware and settings. We show the context (version, host, date) next to each one and never present them as our own results.

Every figure carries a "checked" date: the day we last opened the source and confirmed it still says what we quote.

2. Sizing recommendations

Each app page has a sizing guide. Those rows are our judgment, worked out from the sourced figures on the same page, and they're labelled as recommendations, not measurements. Where a project publishes a formula (for example Nextcloud AIO's "1 GB and 1 vCore per active user"), we apply it and show the arithmetic.

3. Prices

• Prices come only from each provider's own public pricing page, and each table row links to that page.
• Every price shows the date it was checked. Providers change prices and stock often, so check before you buy.
• We rank by the price you'll keep paying: the renewal price when a provider advertises a cheaper intro rate.
• Prices stay in the provider's currency. To rank EUR and USD plans together we convert at the ECB reference rate of the check date.
• If we can't verify a price on an official page, we leave the plan out rather than guess.

4. Our own measurements (in progress)

No app page has VPSfit lab numbers yet. This is the method we'll publish them with:

1. Create a fresh, hourly-billed VPS of a known plan with a current Ubuntu LTS and Docker Engine.
2. Deploy the app with its official Docker Compose file and documented defaults, pinned to a specific version.
3. Let it settle, then record idle memory per container from the cgroup (memory.current and memory.swap.current), not just docker stats, which leaves out swap and reclaimable cache.
4. Run a scripted, repeatable workload for the app (for example a fixed photo import for Immich, concurrent WebDAV clients for Nextcloud, a fixed workflow suite for n8n) and record peak memory, CPU and disk.
5. Repeat at least three times, report the median and the range, and publish the raw JSON alongside the page.
6. Delete the server. Re-measure when a new major version ships.

Each published result will state the app version, plan, region, date and the exact compose file used.

5. Corrections

If a number is wrong or out of date, we want to know. Corrections are dated on the page they affect.