Apps & Software

How Many Containers Does a Self-Hosted App Need?

I counted the services in fifteen self-hosted projects' own compose files. Seven install as a single container, and six reasons explain every extra one.

How many containers a self-hosted app needs — fifteen projects counted from their own compose files

⚡ The short version

Most self-hosted apps are one container. I counted the services in fifteen projects' own published compose files on 14 September 2026, and seven of the fifteen install as a single service — not the four or five that guides, this site included, keep implying. An app needs a second container for one of six specific reasons, and if none of them applies to what you are installing, it does not need one.

Pick up almost any self-hosting guide and the example stack has an app, a database, a cache and something else. It sets an expectation that gets repeated until it sounds like a law: a real self-hosted service is four or five moving parts, and running one is a systems administration project.

I wanted to know how many containers a self-hosted app actually needs, so rather than asking the guides I counted the projects. Every number below comes from a compose file the project itself publishes as its installation method, fetched from its own repository, and the script that fetches them is in this site’s repository so the count can be re-run against whatever those files say next month.

What Did Counting Fifteen Projects Find?

Seven of the fifteen are a single container. Here is the whole count, measured 14 September 2026:

Project Containers What the extra services are
Actual 1
Audiobookshelf 1
Dockge 1
FreshRSS 1
Mealie 1
Navidrome 1
Uptime Kuma 1
RomM 2 MariaDB
SearXNG 2 Valkey
Authentik 3 PostgreSQL, a worker
Karakeep 3 Headless Chrome, Meilisearch
Linkwarden 3 PostgreSQL, Meilisearch
Paperless-ngx 2 to 5 Depends on two questions — see below
Immich 4 Machine learning, Redis, PostgreSQL
Nextcloud 4 PostgreSQL, Redis, cron

The median is two. The mode is one. Nothing in the set reaches five unless you ask Paperless for a feature that most people installing it do not want.

Two of these are a default rather than a ceiling. Mealie publishes an installation page for SQLite, which is the one container above, and a second page for PostgreSQL, which is two (both checked 14 September 2026). Paperless is worse and gets its own section.

Why Did This Site Tell You Four or Five?

Because the apps that get written about are the ones that need the most services, and I wrote about those.

The guides on this site lean on Immich and Nextcloud, which are four services each. Both are near the top of every list of things to self-host, so they are the examples everyone reaches for, and the sentence “a simple self-hosted app is really four or five containers” got written here more than once on the strength of them. Against the count, that sentence is false for a clear majority of the set. Sampling the popular apps and calling the result typical is a mistake that survives precisely because it is never checked, and checking it took one script.

The correction matters beyond tidiness, because the belief has a cost. Somebody who thinks a bookmark manager needs a Postgres instance and a Redis instance puts off installing one, or provisions a server three times the size they need. The honest version is that the large stacks are large for reasons you can read off the file before you commit to anything.

When Does an App Need a Second Container?

When it hands work to a different piece of software rather than doing it in-process. Every extra service in the set above falls into one of six jobs:

The job What it looks like Who does it here
A database it will not do in SQLite postgres, mariadb, db RomM, Authentik, Linkwarden, Immich, Nextcloud
A cache or job queue redis, valkey, broker SearXNG, Paperless, Immich, Nextcloud
A full-text search index meilisearch Karakeep, Linkwarden
A second copy of the app doing background work worker, cron Authentik, Nextcloud
A converter or renderer gotenberg, tika, chrome Paperless, Karakeep
A model runner immich-machine-learning Immich

That list is the part worth keeping, because it predicts. An app that stores text and settings and serves them back needs none of these, which is why Uptime Kuma, Navidrome and Actual are each one container with a data directory. An app that searches inside the contents of the things you saved needs an index, which is why Karakeep and Linkwarden both carry Meilisearch. An app that archives a web page as it looked needs a browser, which is why Karakeep runs a headless Chrome alongside the app that only exists to render pages it is sent (checked in Karakeep’s own compose file, 14 September 2026).

The cache is a separate question from the database. Paperless ships a Valkey broker even in its SQLite configuration, because it queues document processing behind the web request rather than making you wait for OCR. SearXNG does the same thing for search results. Neither is storing your data there, and neither can be dropped to save a container.

Two Containers or Five? The Paperless Question

Paperless-ngx publishes four installation compose files, and the same application is two, three, four or five containers depending on which you copy (all four checked 14 September 2026):

Configuration Containers Services
SQLite 2 broker, webserver
PostgreSQL 3 broker, db, webserver
SQLite with Tika 4 broker, webserver, gotenberg, tika
PostgreSQL with Tika 5 broker, db, webserver, gotenberg, tika

Two questions move it. The first is whether you want PostgreSQL; the project’s own file header says PostgreSQL is used “instead of SQLite (default)”, so the smaller answer is the one the project treats as normal. The second is whether you need Office documents read, which is what Gotenberg and Tika are there for — the same header describes them as providing “support for consuming Office documents (Word, Excel, PowerPoint and their LibreOffice counterparts)”.

If your scanner produces PDFs and photographs of paper, which is the ordinary case, neither converter earns its place. Paperless is then two containers, and the widely repeated claim that it is a five-service monster describes a configuration you were never going to run. The guide to self-hosting Paperless-ngx takes that decision apart and covers what the smaller stack costs you in OCR time and in backup.

Copying the biggest example is the commonest way to end up with a stack you do not need. Projects publish their most featureful compose file prominently because it demonstrates everything. Read the header comments in the file before you copy it — in this set they consistently said, in plain English, what each optional service was for.

What Does Each Extra Container Cost You?

A backup that is no longer one directory, and that is the cost people notice last.

A single-container app keeps its state in a file the container can see, so backing it up means copying one location, and restoring it means putting that location back. Add a database service and the picture changes: copying the database’s files while it is running is the reliable way to produce an archive that will not restore, and the fix is to ask the engine for a dump first. The guide to backing up Docker volumes covers that, and the difference between one service and three is exactly the difference between the easy half of that post and the rest of it.

The second cost is the number of things that can be individually broken. Three services means three images to keep current, three sets of release notes, and failure modes that live between the containers rather than inside one. A search index that will not start leaves an app that runs and returns nothing, which reads as a bug in the app.

✅ Reasons to accept the extra containers

  • You actually want the feature they provide, such as search inside page contents
  • The project treats that configuration as its main path and tests it
  • You already run a database for something else and are comfortable with it

❌ Reasons to take the smaller configuration

  • Backup and restore stay a single directory copy
  • Fewer images to update and fewer places for a failure to hide
  • SQLite is the supported, documented path for these projects rather than a downgrade

None of this is an argument that four containers is bad. Immich needs its model runner to do the thing people install Immich for. It is an argument for knowing which of the two situations you are in before you start, which you can do in about a minute.

How Do You Count an App Before Installing It?

Fetch the compose file the project’s own installation page points at, and ask Compose to list its services:

docker compose -f docker-compose.yml config --services

That prints the service names one per line (Compose CLI reference, checked 14 September 2026). Read the names, not the total. A db and a redis beside the app tell you what you are signing up for; a total of three tells you nothing about whether you can drop one.

The file at the repository root is often not the install method, and it will give you a confident wrong answer. Building this count, four of the files I first collected turned out to be development environments: they built the image from source, pulled a :dev tag, or mounted the repository over the application directory. Three of the four produced the right number anyway, which is why nobody had noticed — a wrong file that agrees with the truth is invisible until it stops agreeing.

Three signs that you are reading a contributor’s file rather than an installation:

  • A build: key instead of an image: line. Installing means pulling a published image; building from the repository is what a contributor does.
  • A bind mount of . into the application directory. That exists so code changes appear without a rebuild, and no installation needs it.
  • A :dev or :local image tag, or environment settings such as a debug log level that no published example would ship with.

Stirling PDF is the honest edge case: the only compose file in its repository is the one that builds the project’s public demo site, and its README documents the installation as a bare docker run with no compose file at all (checked 14 September 2026). One container, and a compose count would have missed it entirely.

If you are new to reading these files, the Docker for self-hosting guide covers what a service, an image and a volume are; this post assumes you can already read the file and only argues about what to count in it. And when the file turns out to declare three services, the Authentik setup is a worked example of what living with that actually involves.

Frequently Asked Questions About Self-Hosted Container Counts

How many containers does a self-hosted app need?

Usually one. Of fifteen projects counted from their own published compose files on 14 September 2026, seven install as a single container, three as two, three as three, and two as four. The count is decided by what the app hands off rather than by how big the app is, so a media server and a bookmark manager can sit on opposite ends of that range.

Why do so many guides show four or five containers?

Because the apps that get written about most are the ones that need the most. Immich and Nextcloud are four services each, and they are also two of the most popular things to self-host, so they set the impression. This site did the same thing for months. The projects nobody writes a guide about are the single-container ones, which is most of them.

Do I need Redis or Valkey if the app already offers SQLite?

Not usually, and the compose file tells you. SearXNG and Paperless both ship a cache or broker service because they queue work between requests, and Paperless does it even in its SQLite configuration. Plenty of single-container apps queue nothing and need neither. Treat the cache as a separate question from the database rather than assuming one implies the other.

How can I count an app’s containers before I install it?

Download the compose file the project’s own installation page points at, then ask Compose to list the services it declares, using the services flag on its config command. It prints the service names one per line. Read the names rather than the total. A file that builds from source or mounts the repository into the container is the contributor environment, not the install, and counting it gives you a number for software nobody runs.

Does running more containers mean it uses more memory?

Probably, but this post does not measure memory and neither should you trust a figure copied from someone else’s server. The count here is a count of services and nothing more. If memory matters for your hardware, run the stack and watch it, because the answer depends on your library size, your settings and how many people use it.

Is a single-container app less capable than a multi-container one?

No. Uptime Kuma, Navidrome and Actual are all one container and all do the job people install them for. The extra services in a larger stack buy specific features, such as full-text search across page contents or machine learning over a photo library. If you do not want that feature, the extra container is cost without benefit.

Product links on this site are plain links. We earn nothing from them — see our disclosure policy.