Open Source Self-Hosted Apps

The honest truth about self-hosting is that the install is the easy part. What decides whether an app earns its place on your server is the six months after, when you are the one patching it, backing it up, and restoring it at 2am. This umbrella covers many jobs at once - photos, media, notes, dashboards, git, chat, monitoring - so the tools below are entry points into different corners rather than a single ranking. What open source adds is leverage you keep: the code is auditable, the data sits on your own disk in formats you can move, and no company can revoke a feature, raise a per-seat price, or shut down the service you depend on.

230 Self-Hosted appsUpdated July 2026
Showing 1-9 of 230

Our picks

Four entry points into different corners of self-hosting, not a ranked best-of.

Best low-risk first service: Uptime Kuma A monitoring dashboard is the classic first service, since downtime is annoying rather than catastrophic while you learn the ropes. Uptime Kuma checks HTTP, TCP, DNS, ping, and Docker containers on short intervals, and alerts you through Telegram, Discord, Slack, email, and dozens more. It runs as a single web app with status pages you can map to your own domains.

The app that justifies the server: Immich A home server often exists to pull a photo library off a third-party cloud, and Immich is built for that. Its mobile apps back up photos and videos automatically, and the web side adds shared albums, multi-user accounts, facial recognition, and search across metadata, objects, and faces. A global map and RAW support round it out.

The glue for a multi-app setup: Nginx Proxy Manager Once you run more than one app, a reverse proxy lets them share a domain over HTTPS, and Nginx Proxy Manager keeps that approachable. Its admin UI handles forwarding hosts, redirects, and free Let's Encrypt certificates without hand-editing Nginx config, while access lists and an audit log control who reaches each service. A short Docker Compose file gets you going.

Best if you would rather run a platform: Coolify If piecemeal installs sound like a chore, Coolify brings hosted-platform convenience to your own VPS, bare metal, or Raspberry Pi. It connects over SSH to deploy apps, databases, and 280-plus one-click services, and writes each configuration to your server so everything keeps running even if you stop using Coolify. That no-lock-in design makes it a safe base layer.

Picking apps that hold up once you are the operator

The first thing to read is not the feature list but the deployment shape, because that is the work you are signing up to maintain. A single Go binary like the one Memos or Uptime Kuma ships is a different commitment than a multi-service stack with its own database, cache, queue, and background workers. Before you fall for an interface, check what it needs underneath and whether it exposes health checks, readable logs, documented configuration, and a way to roll back a bad upgrade. For a home server, boring and well-supported dependencies beat clever ones.

Treat data ownership as something you verify, not a line on a project page. A good self-hosted app tells you exactly where the database, uploaded files, thumbnails, search indexes, secrets, and config live, so a backup captures all of it and a restore into a clean install still has your users, permissions, links, and attachments intact. Favor projects with a documented export or a stable API for your core records; if the only way out is a raw database dump, budget time for cleanup when you eventually move.

Finally, match the security model to how exposed the app will be. Something internal behind a reverse proxy such as Nginx Proxy Manager or Traefik has different needs than a public login page with file uploads, where rate limiting, secure cookies, and multi-factor login matter more. If your household or team already runs central identity, check for OIDC or SAML rather than another set of local accounts, and confirm how the project ships security fixes, since patch timing is now your job.

Related categories

Frequently asked questions

Which app should I self-host first?+

Start with something where downtime is annoying but not catastrophic, so you can learn backups, upgrades, and reverse proxying before the app carries data you cannot replace. A monitoring dashboard like Uptime Kuma is a good candidate: it runs as a single web app, teaches you the whole operating loop, and nothing breaks if it hiccups. Save your only password vault or photo library for after you trust your own restores.

Do I need Docker to run these apps?+

Not always, but it helps. Many projects ship an official container and a short Docker Compose file as the easiest path, and some, like Memos or Gitea, are single Go binaries you can run without containers at all. If you would rather not touch the command line, CasaOS and Coolify wrap installation in a web UI. Docker mainly gives you repeatable setups and clean upgrades, which matters more as you add services.

How do I put several self-hosted apps behind one domain with HTTPS?+

Use a reverse proxy in front of them. Nginx Proxy Manager gives you a web UI for forwarding hosts and issuing free Let's Encrypt certificates without editing Nginx config by hand, which suits a small setup. Traefik instead generates routes dynamically from Docker or Kubernetes and reconfigures without restarts, which fits a stack that changes often. Either one terminates TLS centrally so each app does not need its own certificate.

How much hardware do I need to get started?+

It depends entirely on the app, not on self-hosting in general. Lightweight services scale down remarkably far: Vaultwarden is written in Rust specifically to run where the official server is too heavy, and Uptime Kuma is happy on a Raspberry Pi. Photo and media apps like Immich and Jellyfin are the hungry ones, since facial recognition, thumbnailing, and video transcoding want more CPU, RAM, and disk. Size the machine around your heaviest app.

What backup approach actually lets me recover?+

Back up the database, uploaded files, configuration, and secrets together, and take application-consistent snapshots rather than copying files while the database is mid-write. Keep at least one copy off the server. The step people skip is testing a restore into a clean environment: that is the only way to know whether migrations, file paths, permissions, and encryption keys survived. An untested backup is a guess, not a recovery plan.

How do I update these apps without breaking a working setup?+

Pin versions instead of auto-pulling whatever is newest, read the upgrade notes, and snapshot or back up before you change anything. Watch for database migrations and renamed config keys, since those are what usually bite. Remember that a forward database migration often cannot run against the old application version, so rolling back is not always as simple as pulling the previous image. Where a project supports staging, test there against restored data first.

What happens if a self-hosted app I rely on is abandoned?+

Your exposure comes down to how portable the data and deployment are. If the app uses a standard database, stores files plainly, and offers a working export, you can migrate away or keep running it in isolation while you plan. If it depends on an old runtime, custom storage, or an undocumented format, abandonment turns into a security and recovery problem. Favor projects with clear build instructions, documented schemas, and an exit you have actually tested.