Self-Hosted & Homelab

What does self-hosted mean?

Self-hosted software runs on hardware you control: a mini PC in a closet, a NAS, a rented server. Instead of subscribing to a service, you operate it yourself. The homelab is the matching playground, a small data center at home where Docker containers play the role of the individual apps. One distinction matters: self-hosted and open source are not the same thing. Most projects here are open source, but some vendors license their server component commercially or reserve features for the paid cloud edition. The common denominator is data ownership. Your photos, documents, and sensor data live on your own disk, and no provider can shut the service down, change the terms, or analyze your data. You pay in a different currency: time for setup, updates, and backups. How much time depends heavily on the project, which is exactly where the criteria further down help.

Typical use cases

Replacing Google Photos: Immich automatically backs up phone photos to your own server and offers face recognition, search, and shared albums. It is the most common reason people start a homelab: the cloud storage fills up and the next storage upgrade is due. With your own disk, the setup pays for itself over the years.

Smart home without a vendor cloud: Home Assistant connects devices from different manufacturers locally, automates without an internet connection, and keeps working when a vendor shuts down its cloud. Sensor data from your home stays inside your own network instead of feeding profiles on someone else's servers.

Syncing files without a cloud: Syncthing syncs folders directly between devices, encrypted and without a central server. For many people this is the easiest entry into the topic, because it does not even require an always-on server; two machines are enough.

Remote access to your own machines: RustDesk replaces commercial remote desktop tools like TeamViewer and can run with your own connection server, so screen sessions never cross third-party infrastructure. For family support and remote server maintenance it covers everything you need.

What matters when choosing

Maintenance effort: Every service wants updates, and every unpatched service is an attack surface. Before running something permanently, check how the project ships updates, whether version jumps come with documented migration steps, and how often fundamentals were rebuilt in the past.

Hardware requirements: A Raspberry Pi carries a surprising number of containers but fails at tasks like video transcoding or the image recognition of a photo library. Projects state their requirements in the documentation; Immich, for example, benefits noticeably from more RAM and fast storage.

Project health: For software you trust with your data, what counts is active development and a community that answers questions. A look at release frequency, open issues, and documentation quality tells you more about the next two years than any feature list.

Backups before going live: A service without a tested restore is data loss on a delay. Before migrating your photos or documents, find out how database and files are backed up, and run one restore while nothing important is on the system yet.

Outside access: The most common beginner mistake is exposing services to the internet unprotected. A VPN like WireGuard or an overlay network solves this more cleanly than port forwarding on the router, and much of it never needs to be reachable from outside at all. If a service does need to be public, put a reverse proxy with current certificates and access protection in front of it.

Docker as the common denominator

Almost every self-hosted app ships a Docker image today, and Docker Compose has become the lingua franca of the scene. A Compose file describes the service along with its database and storage paths, one command starts everything, and an update consists of pulling the image and recreating the container. Once you understand Docker, you install the next app in minutes instead of hours, and this repetition effect is what makes homelabs such a good learning environment. Management interfaces like Portainer spare beginners the command line. Maintaining the Compose files yourself still pays off: they double as documentation and as your recovery plan when the hardware fails or you move to a new server.

Frequently asked questions

What hardware do I need for a homelab?

A used office mini PC or a Raspberry Pi is enough to get started, and many people begin on the NAS already sitting in their closet. More important than raw compute are reliable storage and a backup strategy onto a second device. You can upgrade deliberately once a specific service demands more. The projects' community forums quickly show what hardware others use for the same stack.

Is self-hosted more secure than the cloud?

That depends on your discipline. A service reachable only on your home network or via VPN offers almost no attack surface. An unpatched service with an open port, on the other hand, is less secure than any major cloud. Security comes from few exposed services, regular updates, and tested backups, not from self-hosting as such.

Are self-hosted apps free?

The software usually is, the operation not quite: there are power costs, possibly hardware, and your time. Some projects fund themselves through paid extras or a hosted edition, but the core self-hosted functionality typically stays free to use. The project's license page settles any doubt.

The nearly 90 apps above range from a two-minute container to a full weekend project. Start with one service that replaces a concrete subscription; the saved fee then funds the hardware, and the learning curve carries itself.