Sizing

How much machine this actually needs.

RAM and disk per module, what OCR and search cost you, and which two apps in this list will eat a small server on their own.

RAM

Two modules on this site publish real minimums, and both are larger than people expect. Everything else is small enough that the answer is usually "it fits".

Where a project states a figure, it is quoted here. Where it does not, the band is an estimate from typical idle use, not an upstream number, and it is labelled as such.

ModuleRAMSource
Huly8GB minimum, 16GB recommendedUpstream
AppFlowy4GB minimum, 8GB recommendedUpstream
Jitsi MeetGrows with participants, not with idle timeDepends on calls
Docspell with SolrHundreds of MB, mostly SolrEstimate
Paperless-ngx during OCRHundreds of MB, spikyEstimate
Homarr, Dashy, BookStack, Wiki.jsModest, a few hundred MB eachEstimate
PairDrop, PsiTransfer, Kiwix, BentoPDFSmallEstimate
Take the Huly figure literally. Upstream warns that servers below the minimum may stop responding or fail outright. Eight gigabytes is the floor for that one service, not for your whole stack. On a NAS with 4GB soldered in, Huly is not an option and no amount of tuning changes that.

The practical answer for most people: 8GB runs a comfortable stack without the two large workspaces. 16GB runs anything on this site. 4GB runs a wiki, a forge, a dashboard and file transfer, which is a genuinely useful server.

Disk

Disk is where a workspace server surprises you, and it is almost always one of three things.

Paperless-ngx
Keeps the original and a processed archive version of each document, so budget roughly double what you are scanning
Kiwix
ZIM files are the whole cost. A full Wikipedia with images is very large; the no-pictures build is far smaller. Check current sizes on the Kiwix download site before committing
Forgejo or Gogs
Repository history, which grows quietly, plus package registry storage if you use it

Everything else is small by comparison. Wikis, dashboards and PDF tools store text, configuration and thumbnails.

Put the archive on the big disk, not the fast one. If you have an NVMe drive and a spinning disk, databases and the OS go on the NVMe. Scanned documents and ZIM files go on the spinning disk. They are read occasionally and written once.

Watch growth rather than guessing at it. A monthly look at du -sh across your bind-mount directories will tell you which module is actually growing, which is rarely the one you expected.

CPU and OCR

Almost nothing here is CPU-bound. The exceptions are OCR and video.

OCR is the one that will make a slow machine feel slow. Paperless-ngx and Docspell both run it on every incoming document, and it scales with page count. On a mini PC this is unnoticeable. On a Raspberry Pi it turns a bulk import of several hundred documents into an overnight job. If you are migrating an existing archive, start it before bed rather than before a meeting.

Video in Jitsi is different: the videobridge forwards streams rather than transcoding them, so CPU load tracks the number of participants in a call rather than sitting constant. An idle Jitsi install costs you almost nothing. A ten-person call costs you real bandwidth, more than it costs you CPU.

Everything else in this list spends most of its life waiting for a request that never comes. Do not buy a current-generation processor to run a wiki.

Backups

Three categories, and they need different treatment.

  1. Bind-mount directories. Copy them. If your compose file and these folders are backed up, you can rebuild the stack on a new machine.
  2. Databases. Do not copy the files while the database is running. Take a dump: docker compose exec db pg_dump -U user dbname > dump.sql for PostgreSQL, the mysqldump or mongodump equivalent otherwise. A file-level copy of a live database restores as a corrupt database, and you usually find out at the worst moment.
  3. Application-level exports. Several apps have their own export that survives a version change better than a raw backup does. Paperless has a document export, Wekan exports boards as JSON with attachments, BookStack and Wiki.js both export content. Run one occasionally even if you have file backups.
An untested backup is not a backup. Restore one into a scratch directory and start the stack against it. The first restore always reveals something: a missing environment variable, a permission mismatch, a secret that only existed in the running container. Find that out deliberately rather than during an outage.
Back up your secrets separately. Homarr's encryption key, BookStack's APP_KEY, Zipline's CORE_SECRET and OpenSign's MASTER_KEY are not in any volume. They are in your .env file. Lose that and a perfect data backup still will not start.

Example builds

Three stacks that make sense together, sized honestly.

The small one. 4GB, any machine that stays on.

BookStack, Forgejo, PairDrop, Dashy. A wiki, your code, a way to move files around the house, and one page that links it all. Runs comfortably on a Raspberry Pi 5 or an older NAS. No OCR, so nothing is CPU-bound.

The usual one. 8GB, a second-hand mini PC.

Everything above plus Paperless-ngx with Redis and PostgreSQL, Stirling-PDF, PsiTransfer and Homarr. This is the stack most people who read this site end up with. OCR is fast enough that scanning becomes a habit rather than a chore.

The large one. 16GB and a real domain.

Everything above plus CryptPad on its two domains, Jitsi Meet with UDP open, and either AppFlowy or Huly deployed from its own repository. At this point you are running infrastructure rather than a few containers, and the backup section stops being optional.

Notice what is missing from all three: you do not need two wikis, two forges or three PDF tools. Pick one per job and add the second only when you have a reason. Docs has the comparison for each pair.