A Practical Guide to Self-Hosting: One Developer's Experience

Self-hosting is moving from a niche hobby into the broader developer community. As cloud service prices rise, privacy controversies flare up, and API policies shift unpredictably, more and more technical people are re-examining the idea of "keeping data and services in their own hands."

Recently, a Hacker News post titled "What I Self-Host" sparked a large discussion. The author systematically laid out the list of self-hosted services they actually deploy and run long-term, while the comment section contributed a range of differentiated hands-on experience. This article combines the original post with community feedback to paint a realistic picture of the self-hosting landscape.

What Are the Core Motivations for Self-Hosting

The reasons given by the original author aren't complicated: control and cost. As SaaS products tighten free tiers and subscription prices rise year after year, a VPS costing a few dollars a month or old hardware at home can host a surprising number of services. This cost structure is especially appealing to individual users and small teams.

Another high-frequency motivation in the community discussion is data sovereignty. Email, notes, photos, passwords—the value of this data far exceeds the storage cost, but once it's handed to a third party, migration costs and privacy risks rise in parallel. Self-hosting makes exporting and backing up something under your own control.

The third motivation is more technical: learning and mastery. Operating a service that actually runs in production exposes real issues in networking, DNS, TLS, backup and recovery far more than running demos in a sandbox. For developers, this itself is an investment in skills.

Common Self-Hosted Service List

The original post's list covers several typical categories, and community replies largely revolve around these same directions.

Infrastructure and Network Layer

A reverse proxy is almost the starting point for every self-hosting setup. Nginx, Caddy, and Traefik are the most frequently mentioned choices in community discussions, with Caddy earning a good reputation in personal scenarios thanks to its automatic HTTPS certificate management. On the DNS side, many people build their own AdGuard Home or Pi-hole for local ad blocking and domain resolution.

VPN and remote access are also key. WireGuard, due to its simple configuration and good performance, has a noticeably higher adoption rate in the self-hosting community than OpenVPN. Combined with networking tools like Tailscale, you can access home network services without exposing public ports.

A reverse proxy is a key component in self-hosted architecture. It sits between clients and backend services, forwarding external requests to the correct internal service instance. Unlike a forward proxy, which accesses the internet on behalf of the client, a reverse proxy receives requests on behalf of the server, enabling unified TLS termination, domain routing, load balancing, and access control. In self-hosting scenarios, a single reverse proxy can let one VPS host services on multiple subdomains without exposing ports or configuring certificates separately for each service. Caddy is popular among individual users because it has built-in capability to automatically request and renew Let's Encrypt certificates, greatly lowering the barrier to HTTPS configuration.

WireGuard is a modern VPN protocol designed for simplicity, high performance, and strong encryption. It runs as a kernel module on Linux, and its codebase is far smaller than OpenVPN, making it easier to audit and lower in latency. In self-hosting scenarios, WireGuard is often used to establish encrypted tunnels from external devices to a home network, allowing access to internal services without opening public ports. Tailscale builds an automated peer-to-peer networking layer on top of WireGuard, using coordination servers to help nodes discover each other and establish direct connections, further reducing the complexity of manually configuring keys and routes.

Data and Productivity Tools

Among note-taking apps, Obsidian with a self-built sync solution, or directly deploying Outline or Trilium, are common paths. For password management, Vaultwarden (a lightweight, compatible implementation of Bitwarden) is repeatedly mentioned for its low resource usage and complete feature coverage.

In the file sync space, Nextcloud remains the most discussed option, but some users point out its high maintenance cost and switch to Seafile or the lighter-weight Syncthing for peer-to-peer sync.

Vaultwarden is a lightweight open-source compatible implementation of the Bitwarden server API, written in Rust. It is fully compatible with official clients, so users can use Bitwarden's browser extensions, desktop, and mobile apps while storing data on a server they control. Compared to the official server, Vaultwarden uses extremely few resources and runs smoothly on a Raspberry Pi or low-spec VPS, while supporting core features like organizations, attachments, and two-factor authentication. For users who want to self-host a password manager, Vaultwarden is often the most cost-effective choice.

Syncthing is an open-source continuous file synchronization tool with a peer-to-peer architecture that doesn't rely on a central server. Each device identifies others via device IDs and establishes encrypted connections, with file changes propagating directly between devices. This design means data doesn't pass through a third-party cloud drive, making it suitable for users who are privacy-sensitive or want high-speed sync within a local network. Compared to full private cloud platforms like Nextcloud, Syncthing focuses solely on sync, making deployment and maintenance simpler, but it lacks collaboration capabilities like a web interface, online editing, and shareable links.

Media and Subscription Management

Media servers are one of the most active branches in the self-hosting world. Jellyfin, as an open-source alternative, continues to gain support in the community, while Plex retains a large user base thanks to its client experience. RSS readers (such as FreshRSS and Miniflux) also frequently appear on lists; self-hosting these tools completely eliminates the risk of third-party services shutting down.

The Real Costs and Pitfalls of Self-Hosting

Both the original author and commenters noted that the hidden costs of self-hosting are often underestimated.

Maintenance time is real money. Service updates, dependency upgrades, certificate renewals, and log troubleshooting don't disappear just because you're an individual user. One commenter's perspective is very representative: every self-hosted service should be treated as a long-term commitment, not a one-time deployment.

Backups matter more than deployment. The community consensus is that a backup without a recovery drill is no backup at all. The 3-2-1 strategy (three copies, two media types, one offsite) applies equally to self-hosting scenarios.

The security exposure surface expands. Once a service is exposed to the public internet, scanning and brute-force attacks become the norm. Practices repeatedly emphasized in the comments include: using VPNs or zero-trust gateways instead of direct port exposure wherever possible, enabling two-factor authentication, and keeping up with security updates.

Single point of failure risk. Self-hosting means you are the ops team. Hardware failures, home network outages, and misoperations can all cause service unavailability, so you need to think ahead about which services can tolerate downtime.

A 3-2-1 backup strategy is a widely recognized disaster recovery principle: keep at least three copies of data, use two different storage media, and ensure one copy is stored offsite. In self-hosting scenarios, three copies usually means production data, a local backup, and an offsite backup; two media types can be internal drives and external drives or tape; and the offsite copy can be achieved through object storage, a remote server, or a device at a friend's or family member's home. The core purpose of this strategy is to handle different types of failures—disk corruption, accidental deletion, fire or theft, etc.—ensuring that no single event causes permanent data loss. A backup that hasn't been tested through a recovery drill can't be confirmed as valid, so periodically actually restoring data from backups is an indispensable part of the strategy.

Advice for Developers Getting Started

Drawing on both the original post and community discussion, a few pragmatic paths are worth considering.

Start with the services that deliver the most value at the lowest maintenance cost, such as password managers and DNS filtering—these two categories offer intuitive benefits with manageable failure impact. Then move on to data-sensitive services like notes and file sync.

Use containerization to reduce deployment complexity. Docker Compose is a common starting point for personal self-hosting, and paired with tools like Watchtower for image updates, it can significantly reduce manual maintenance.

When choosing solutions, prioritize community activity and data exportability. Whether a project is still actively updated, whether documentation is thorough, and whether all data can be exported if something goes wrong are more important than a feature list's richness.

Finally, include "what not to do" in your planning. Not every service is worth self-hosting—email server anti-spam and deliverability issues, video transcoding compute requirements, often make the cost-benefit ratio unfavorable. A reasonable mix of cloud services and self-hosting is the sustainable approach.

Watchtower is a tool for automatically updating Docker container images. It periodically checks whether new versions of the images used by running containers are available, and when updates are found, automatically pulls the new image and restarts the container with its original configuration. For personal self-hosted environments, Watchtower can significantly reduce the frequency of manually running docker pull and docker compose up, lowering the risk of accumulated security vulnerabilities from forgotten updates. However, automatic updates also mean new versions may introduce incompatible changes, so it's recommended to combine it with a notification mechanism, or use manual updates for critical services and verify them in a test environment first.

Summary

The value of the "What I Self-Host" post isn't in providing a standard answer, but in presenting a pragmatic set of trade-offs: self-hosting is a redistribution of control, and every deployment comes with a transfer of responsibility. Understanding the real operating costs of these services is more meaningful than copying a list.

One-line Summary

A pragmatic overview of self-hosting, from motivations and common service lists to hidden costs and getting-started advice.

Paragraph Summary

This article combines the original "What I Self-Host" post on Hacker News with community discussion to outline the motivations, common services, and real costs of self-hosting. Core motivations include cost control, data sovereignty, and the learning value of operations. Common services cover reverse proxies (Nginx, Caddy, Traefik), DNS filtering (AdGuard Home, Pi-hole), VPNs (WireGuard, Tailscale), password management (Vaultwarden), file sync (Nextcloud, Seafile, Syncthing), media servers (Jellyfin, Plex), and RSS readers. The article emphasizes that hidden costs are often underestimated: maintenance time, backup strategy, and security exposure are the three major challenges, with backups requiring the 3-2-1 strategy and recovery drills. Getting-started advice includes beginning with low-maintenance, high-value services like password managers and DNS filtering, using Docker Compose and Watchtower to reduce operational burden, prioritizing solutions with active communities and exportable data, and reasonably mixing cloud services with self-hosting.