Where it runs

Pick the box before you pick the apps.

NAS, mini PC, VPS or an old laptop. What each one can carry, and the point at which a stack outgrows it.

NAS

If you already own a NAS with a Docker or Container Manager app, use it. The disks are the expensive part and you have already bought them.

Synology, QNAP, UGREEN, TerraMaster and Asustor all run containers, with varying amounts of friction. The web UI they give you for it is usually worse than the command line. If you can enable SSH, do, and use compose files rather than the graphical container editor. You get something you can back up and re-create.

What to check before you plan a stack:

  • RAM, and whether it is upgradeable. Many two-bay units ship with 2GB soldered. That is enough for a wiki and a dashboard. It is not enough for Paperless with OCR running.
  • CPU architecture. Some cheaper units are ARM, and a few images here are amd64 only.
  • Whether the vendor has taken ports 80 and 443. On Synology in particular the built-in web station may hold them, which complicates running your own reverse proxy.
The consume folder is the thing to plan for. If you run Paperless-ngx, put its consume directory on a network share the scanner can already write to. That one decision is the difference between scanning being a habit and scanning being a chore.

Mini PC and home server

A second-hand mini PC is the best value in this whole comparison, and it is what this site recommends if you are buying something.

An ex-office machine with a recent Intel chip, 16GB of RAM and an NVMe drive covers everything on this site including the heavy modules, runs silently, and draws maybe ten watts idle. Refurbished units of this kind routinely sell for less than three months of a comparably specified VPS.

The tradeoffs are honest ones. It lives in your house, so your upload speed is your upload speed, and a power cut is an outage. It has one disk unless you add more, so backups are your responsibility rather than a RAID array's.

What to look for. 16GB RAM, an NVMe slot, and a spare SATA bay or a USB enclosure for backups. Anything from the last five or six years is fine. Do not pay for a current-generation machine to run web applications that spend most of their time idle.

VPS

A VPS gives you a static IP, real upload bandwidth, and someone else's power supply. It costs monthly, forever, and storage is where it hurts.

The pattern that catches people is buying a cheap plan for the RAM, then discovering that a document archive fills the 40GB of included disk within a year, and that block storage is billed per gigabyte per month on top. A scanned-document archive with OCR grows faster than people expect, because Paperless keeps both the original and a processed version.

A VPS is the right answer when you need the stack reachable from anywhere with no fuss, when you are sharing it with people outside your house, or when your home connection genuinely cannot serve it. For a personal archive on a home network, it is money spent on a problem you do not have.

The middle option. Run the stack at home and put only the reverse proxy on a cheap VPS, connected over a VPN. You get a public address without renting storage. Access covers how, along with the tunnel services that do the same job without a server.

Raspberry Pi and ARM

A Raspberry Pi 5 with 8GB runs a useful subset of this list. A Pi 4 with 4GB runs a smaller one. Neither is a good home for a document archive.

Two constraints do the damage. OCR is CPU-bound, and a Pi will take several times longer per page than a mini PC, which turns a bulk import into an overnight job. And SD cards fail under sustained database writes. If you run anything with Postgres on a Pi, boot from an SSD over USB.

What works well on a Pi: BookStack, Gogs, PairDrop, PsiTransfer, Dashy, Homarr, Kiwix. What does not: Paperless-ngx with a large backlog, Docspell, AppFlowy, Huly, Jitsi Meet.

Check the architecture before you commit. A Pi is arm64. Most images here publish arm64 builds, but not all do, and an image that does not will fail at start with an exec format error rather than anything more helpful.

Windows and macOS

You can run this on the machine you use every day. Both scripts detect which one you are on and say what it means before they touch anything, but the constraints are worth knowing first.

Windows

Use Docker Desktop with the WSL2 backend, and keep everything inside the Linux filesystem.

Do not put your data under /mnt/c. Files on the Windows drive are reached through a translation layer: they are slow, and they lose Unix ownership entirely. Anything that checks file permissions, which is most of this list, behaves unpredictably. Put the stack in your WSL home directory instead.

If you run the scripts from Git Bash rather than WSL, it rewrites arguments that look like paths, so a container path such as /app/data can arrive mangled. Prefix the command with MSYS_NO_PATHCONV=1 when that happens. The generated scripts warn you when they detect Git Bash.

Line endings matter too. The generated install.sh uses Unix line endings. If you open it in an editor that converts them, sh fails with an unhelpful error about a missing command.

macOS

Docker Desktop runs containers inside a Linux VM, which has two consequences.

  • Bind mounts are slower than on Linux. Noticeable on anything doing lots of small writes, which here means databases and OCR.
  • PUID and PGID do not work the way they do on Linux. The VM handles the mapping for you. Set them from id -u and id -g anyway, which on macOS is usually 501 rather than 1000, so that the same compose file behaves correctly if you ever move it to a Linux box.

Also: macOS ships bash 3.2, which is from 2007. Everything generated here is POSIX sh for that reason. If you copy a snippet from another guide and it fails with a syntax error, that is usually why.

Neither is a bad choice for trying this out. They are a poor choice for something that should stay up, because the stack stops when you close the laptop. Move it to a machine that stays on once you know which modules you keep.

Side by side

PlatformUp-frontOngoingBest forWeak spot
Existing NASNothingPowerAnyone who already owns oneSoldered RAM, vendor holds ports 80 and 443
Mini PCLow, second-handPowerBest value overallYour upload speed, single disk
VPSNothingMonthly, storage billed extraSharing with people elsewhereStorage cost grows with the archive
Raspberry PiLowVery little powerSmall stacks, low drawOCR speed, SD card wear
Windows desktopNothingPowerTrying it outKeep data out of /mnt/c, and it stops when you shut down
MacNothingPowerTrying it outSlow bind mounts, and it stops when you close the lid

If you are undecided and already own a machine that stays on, use it. Buy something only once you know which modules you actually keep using. Hardware has the per-module figures to size against.