SelfHostMap

How we test

Every app page has two kinds of numbers. Official figures come from the project's own docs and link to them. Measured figures measured come from deploying the app ourselves. We never mix the two, and we never fill a gap with a guess.

Official facts

License, official hardware, deploy command and documented gotchas are read from the project's repository, license file and docs, with the source linked on the page. If the docs don't state something, the field stays empty. GitHub activity (stars, releases, last commit) is refreshed automatically every day.

Our deployment tests

So far we have tested 11 apps: n8n, Ollama, Open WebUI, Langflow, llama.cpp, NextChat, AnythingLLM, LibreChat, Qdrant, Activepieces, LibreTranslate. Each test follows the same procedure:

  1. Official instructions only. We use the Docker or Compose command from the project's docs. The usual changes are a memory cap (--memory) and -d instead of an interactive terminal. Occasionally we must pin a version tag (when :latest is out of date), add a setting the app refuses to start without, or point a chat UI at a local model instead of a cloud API key. Every such change is listed under the command on each page.
  2. Record the version. We note the image tag and digest and the app's own version number, plus the test date.
  3. Image size. We record the compressed download size and the size on disk once unpacked, and the app's data folder after the test.
  4. Start-up time. We time from docker run until the app answers its health URL with HTTP 200 (or logs that it's ready) on first boot, with the image already downloaded. We report the download time separately because it depends on your network. Ours is a datacenter connection.
  5. Idle RAM. 2 minutes after start, from docker stats (MEM USAGE, which excludes page cache).
  6. Working RAM. We do one small, realistic task: log in and use the editor, run a workflow, or send a chat message. Memory is sampled every 2–3 seconds and we report the highest reading. For model runners we also record model file size, RAM while answering, and tokens per second on CPU. Chat UIs talk to a tiny local model (Qwen2.5 0.5B) in a separate container, which is not counted in the app's RAM. For Docker Compose stacks we add up all of the stack's containers.
  7. Snags. Every warning or error we hit, with the exact text and what fixed it. If a problem came from our own test network rather than the app, we say so.
  8. Screenshots of the running UI, taken with headless Chrome.
  9. Clean up. Containers, volumes and images are removed after each test, and apps are tested one at a time.

If something could not be measured, the page says "not measured" instead of showing a number.

Test machine

MachineSelfHostMap test VM (Oct 2026)
CPUIntel Xeon (Sapphire Rapids class, AVX-512 + AMX), 8 vCPU
RAM16 GB (shared)
GPUnone (CPU only)
SoftwareDebian 13 (trixie), Linux 6.12, Docker Engine 29.9.2
NotesShared cloud VM. Other workloads were running, so each container was capped with docker --memory and tested on its own. RAM figures are the container's own usage (docker stats MEM USAGE, page cache excluded), not the whole machine.

This is a fast, modern CPU. On a small 2–4 vCPU VPS, start-up and especially model speed (tokens per second) will be slower. RAM use is roughly similar, but it grows with your data, number of users and model size.

Cost from measured RAM

When a project publishes an official RAM figure, our cost estimate uses that figure. When it publishes none, and only then, we derive an estimate from our test and label it based on our test:

needed RAM = measured working RAM × 1.5 + 512 MiB (headroom for the OS, Docker and spikes), then the cheapest Hetzner Cloud Regular Performance (shared AMD vCPU) plan with at least that much RAM. Prices are list prices read from www.hetzner.com/cloud/regular-performance on 2026-10-22, excluding VAT, server only.

Limits

Spotted a number that doesn't match your experience? Tell us with your version and setup.