Owning your own tools used to mean owning a server. In 2026 it mostly means owning a container. The best self-hosted apps ship as a Docker image, start with one command, and give you a private alternative to a monthly SaaS subscription. The catch has always been the last mile: putting that container somewhere it runs reliably, over HTTPS, with a database and backups, without turning you into a part-time sysadmin.
This guide walks through the best self-hosted apps to run in Docker, organized by category, with a one-line description and how each one actually runs as a container. Then it covers the honest total cost of ownership, so you know when self-hosting saves money and when a managed plan wins.
The short answer: the best self-hosted apps in Docker in 2026 are Plausible or Umami for analytics, n8n for automation, Ghost or Directus for content, Uptime Kuma and Grafana for monitoring, and MinIO for object storage. Each runs from an official image, needs a Postgres or Redis database, and a persistent volume for its data.
What Is a Self-Hosted App?
A self-hosted app is software you run on infrastructure you control instead of paying a vendor to run it for you. You get the same features as the SaaS version, but the data lives in your environment, you set the retention rules, and there is no per-seat subscription. Most modern self-hosted apps are distributed as a Docker image, which is what makes them practical to run without deep operations knowledge.
The distinction that matters is between the application and the server it runs on. A traditional self-host means renting a virtual machine, installing Docker, wiring a reverse proxy, and renewing TLS certificates yourself. A container-first approach means handing an image to a platform that runs it and manages routing, certificates, and scaling for you. Both are "self-hosting" in the sense that you own the data and the configuration. The second removes the server from your job description.
The Best Self-Hosted Apps by Category
Every app below is open source, actively maintained, and ships an official container image. For each one, the important operational facts are the same three: which port it listens on, whether it needs a database, and whether it needs a persistent volume for its files.
| App | Category | Needs a database | Needs a volume |
|---|---|---|---|
| Plausible | Web analytics | Postgres + ClickHouse | No |
| Umami | Web analytics | Postgres | No |
| n8n | Automation | Postgres | Yes (files) |
| Ghost | CMS / newsletter | Postgres | Yes (images) |
| Directus | Headless CMS | Postgres | Yes (uploads) |
| Uptime Kuma | Monitoring | Built-in | Yes (data) |
| Grafana | Dashboards | Postgres | Yes (plugins) |
| MinIO | Object storage | None | Yes (buckets) |
| Metabase | Business intelligence | Postgres | No |
| Vaultwarden | Password manager | Built-in / Postgres | Yes (vault) |
Analytics
Privacy-friendly analytics is the most common first self-host, because it replaces a tracker you would rather not run and keeps visitor data in your own database.
- Plausible is a lightweight, cookie-free web analytics tool that reports the numbers most teams actually read. It runs as a container that talks to a Postgres database for configuration and an event store for pageviews, so you point both connection strings at managed instances and it starts collecting.
- Umami is an even simpler single-container analytics app backed by one Postgres database. It listens on a fixed port, reads its database URL from an environment variable, and needs no persistent volume because everything lives in Postgres.
Automation and Workflows
- n8n is a visual workflow automation tool that connects APIs, webhooks, and databases into pipelines you build by dragging nodes. As a container it stores workflow definitions in Postgres and keeps a small volume for binary data and credentials, so a managed database plus one volume is the entire footprint.
Content and Publishing (CMS)
- Ghost is a publishing platform for blogs and newsletters that is faster and leaner than the older PHP-based options. The container reads its database from a connection string and needs a persistent volume for uploaded images and themes, so pair it with managed Postgres and a mounted volume.
- Directus is a headless CMS that wraps any SQL database in an admin UI and a REST or GraphQL API. It runs as a single container against Postgres, with a volume for uploaded assets, which makes it a clean back end for a separate front-end app.
Monitoring and Uptime
- Uptime Kuma is a self-hosted status-and-uptime monitor that pings your services and alerts you when one goes down. It stores everything in an embedded database file, so it needs only a persistent volume and a single port to run.
- Grafana is the dashboarding layer that turns metrics and logs into panels. It runs as one container, uses a Postgres database to store dashboards and users, and keeps a small volume for installed plugins.
Storage and Files
- MinIO is an S3-compatible object storage server, so any app that already speaks the S3 API can point at it instead of a cloud bucket. It needs no external database and stores objects on a persistent volume, which makes the volume the one part of a MinIO deploy you must size correctly up front.
Handy Extras
- Metabase is a business-intelligence tool that lets non-engineers ask questions of your database through a UI, backed by its own Postgres for saved questions.
- Vaultwarden is a lightweight, self-hosted password-manager server compatible with popular Bitwarden clients, storing its vault on a persistent volume.
How These Containers Actually Run
The reason all of these apps feel similar to operate is that they follow the same container contract. A good host builds from a repository that has a Dockerfile, or runs the official image directly from a registry with no rebuild. Either way, three details decide whether the app works in production.
First, the process must listen on 0.0.0.0 and the port the platform provides. Many self-hosted images default to a fixed port like 3000 or 8080, so you map that to the platform's PORT variable. Binding to localhost is the single most common reason a container starts cleanly but never receives traffic.
Second, stateful apps need a persistent volume. According to the official Docker documentation, volumes are the preferred mechanism for persisting data generated by a container, because the container filesystem itself is ephemeral and disappears on every redeploy. Ghost images, n8n workflow files, and MinIO buckets all belong on a volume, not in the container.
Third, most of these apps expect a database connection string in an environment variable. Rather than run Postgres in another container you have to back up yourself, you provision a managed database and paste its URL into the app's config. That single choice removes an entire category of maintenance work.
Here is what running one of these apps looks like when you deploy the official image and hand it the two things it needs. On a platform you set these as configuration rather than typing a raw command, but the shape is identical.
# n8n against a managed Postgres, listening on the platform PORT
docker run -d \
-e DB_TYPE=postgresdb \
-e DB_POSTGRESDB_HOST=$DATABASE_HOST \
-e DB_POSTGRESDB_DATABASE=$DATABASE_NAME \
-e DB_POSTGRESDB_USER=$DATABASE_USER \
-e DB_POSTGRESDB_PASSWORD=$DATABASE_PASSWORD \
-e N8N_PORT=$PORT \
-v n8n_data:/home/node/.n8n \
docker.n8n.io/n8nio/n8nThe environment variables carry the database credentials, the port matches what the platform routes to, and the volume keeps workflow files across restarts. Swap the image and the variable names and the same three-part pattern deploys Ghost, Directus, or Grafana.
Managed vs Self-Hosted: The Real TCO
The pitch for self-hosting is "stop paying the subscription." That is real, but the subscription is only one line in the total cost of ownership. The honest comparison weighs the SaaS bill against the compute, storage, and, most importantly, your time.
| Cost factor | Managed SaaS | Self-hosted on a raw server | Self-hosted on a PaaS |
|---|---|---|---|
| Monthly software fee | Per-seat subscription | None | None |
| Compute and storage | Included | You rent and size it | Usage-based |
| Server patching and OS upgrades | Vendor | You | Platform |
| TLS certificates and routing | Vendor | You configure | Automatic |
| Database backups and recovery | Vendor | You script and test | Managed |
| Upgrades to the app itself | Vendor | You | You (one redeploy) |
| Your time per month | Near zero | Several hours | Near zero |
The middle column is where self-hosting quietly gets expensive. A $5 virtual machine looks cheaper than a SaaS plan until you count the evening you spent renewing a certificate or restoring a database that had no tested backup. That labor is the hidden line item, and it is exactly the work a platform-first approach removes. For a deeper look at when to draw this line, see self-hosted vs managed PaaS.
Self-hosting wins clearly in two situations. The first is data control: when the data must stay in your environment, run the app yourself and the subscription math stops mattering. Running in an EU region for European data residency is a common reason teams choose this path. The second is scale of usage: once a per-seat SaaS bill grows with your team, a single container serving everyone can be dramatically cheaper. The right-hand column, self-hosting on a platform, is what makes those wins accessible without the sysadmin tax of the middle column.
You do not need a container orchestration cluster to run five self-hosted apps. That path adds far more operational surface than a handful of stateful containers justify. If you have been told the answer is a full cluster, read Kubernetes overkill alternatives first, then compare it to running each app as a plain container. For the mechanics of running any image in production, the Docker hosting guide covers the deploy paths end to end.
A Practical Way to Run Them
The cleanest setup for a small stack of self-hosted apps is one platform that runs each container, provisions the databases they need, and keeps their volumes persistent. On Out Plane you deploy each app from its official image or a connected repository, attach a managed PostgreSQL or Redis instance for the apps that need one, and mount a volume for the apps that store files. Every app gets a custom domain with automatic HTTPS, there are no cold starts so a monitoring dashboard is always awake, and per-second billing means a low-traffic tool costs little to keep running.
Because compute is metered by the second and the Hobby tier is permanently free with up to 3 instances, you can run a couple of small self-hosted apps continuously at no cost and only pay when one grows. Regions include Nuremberg, Helsinki, Ashburn, Hillsboro, and Singapore, so you can keep European users' data in an EU region without extra configuration.
If you are self-hosting your first app, start with one container and one managed database, confirm it listens on PORT, and mount a volume before you put any real data in it. If you are consolidating several tools off separate subscriptions, put them on one platform so they share a single bill and a single deploy workflow.
Ready to run your own tools? Deploy a self-hosted app on Out Plane with $20 in free credit and no credit card required. See the full breakdown on the pricing page.
Frequently Asked Questions
What are the best self-hosted apps to run in Docker?
The best self-hosted apps in Docker in 2026 are Plausible or Umami for analytics, n8n for automation, Ghost or Directus for content, Uptime Kuma and Grafana for monitoring, and MinIO for object storage. Each ships an official container image, needs a managed database or an embedded one, and stores its state on a persistent volume, which makes them straightforward to run on a modern platform.
Do I need my own server to self-host an app?
No. You can run a self-hosted container on a platform that manages the server for you, so you never patch an operating system or configure a reverse proxy. You hand the platform the image or the repository, it runs the container over HTTPS, and you keep full control of the app's data and configuration. Out Plane runs each app this way with a managed database and automatic HTTPS.
Which self-hosted apps need a database?
Most do. Plausible, n8n, Ghost, Directus, Grafana, and Metabase all read a database connection string from an environment variable, usually pointing at Postgres. Uptime Kuma and Vaultwarden can use an embedded database instead, and MinIO needs no database at all because it stores objects on a volume. Provisioning a managed database removes the backup and recovery work from your plate.
Why does my self-hosted container start but load nothing?
The usual cause is the app listening on a fixed internal port or on localhost instead of the port the platform routes to. Set the app's port variable to the platform's PORT value and make sure it binds to 0.0.0.0. If the app also loses its data on every deploy, it is missing a persistent volume, which the container filesystem cannot replace.
Is self-hosting actually cheaper than SaaS?
Sometimes. Self-hosting removes the per-seat subscription, but you still pay for compute and storage, and on a raw server you also pay in time for patching, certificates, and backups. On a usage-billed platform the compute cost is small and the maintenance cost drops to near zero, which is where self-hosting reliably beats a growing per-seat SaaS bill.
Can I run several self-hosted apps on one platform?
Yes. You can run analytics, automation, a CMS, and a monitor as separate containers on the same platform, each with its own domain and its own scaling. They can share managed databases where it makes sense, and each app redeploys independently, so upgrading one does not touch the others. Keeping them on one platform means one bill and one deploy workflow.
How do I keep a self-hosted app's data safe across deploys?
Store the app's state on a managed database and a persistent volume, never inside the container. The container filesystem is ephemeral and is discarded on every redeploy, so anything not on a volume or in the database is lost. On Out Plane the managed database handles backups, point-in-time recovery, and read replicas, and volumes persist your app's files between releases.