What deserves to be self-hosted?

A practical way to decide which services belong on your own hardware and which ones are better handled elsewhere.

← All field notes

Self-hosting begins with a simple feeling: I could run this myself.

Then comes the container, the domain, the reverse proxy, the certificates, the database, the backup job, the monitoring, the update schedule, and the quiet realization that a useful application has become a small production system in your house.

I enjoy that process. It is one of the reasons I have a homelab. Running a service teaches you what the polished interface usually hides. You learn where the data lives, which dependencies matter, how authentication works, and what failure looks like.

The ability to self-host something is only the first question.

The more important question is whether it deserves to be self-hosted.

Start with the consequence of failure

Every service has a failure cost.

If a recipe manager is unavailable for an hour, dinner will survive. If the password manager disappears while the family is travelling, the problem becomes more serious. If home automation controls the lights, locks, heating, or an alarm, reliability reaches into the physical house.

The first decision should come from consequence rather than technical interest.

Ask what happens when the server is down, the internet connection fails, the database becomes corrupted, or you are away from home. Ask who else depends on the service. Ask whether a temporary failure is annoying, expensive, dangerous, or irreversible.

A low-consequence service is a good place to experiment. A high-consequence service needs mature operations from the beginning.

Data ownership can justify the work

Some services hold information worth keeping close.

Personal documents, family photos, home-camera recordings, location history, health information, and private notes all have value beyond their file size. Self-hosting can give you direct control over storage, retention, access, and deletion.

Control carries responsibility. You become responsible for encryption, account security, updates, hardware failure, and recovery. A private server with weak authentication can expose more data than a well-operated hosted service.

CISA recommends reducing the number of systems exposed directly to the internet. For services that must remain accessible, its guidance includes changing default passwords, installing security patches, replacing unsupported software, monitoring traffic, and using multifactor authentication.

Remote access deserves a deliberate design. A VPN or secure access layer can keep administration interfaces away from the public internet. Public services should expose the smallest practical surface. Every open port and login page becomes part of the maintenance commitment.

A backup has to survive the server

Self-hosted data needs a recovery path that exists outside the system being protected.

A mirrored disk can keep a service running after a drive failure. It remains part of the same machine. Accidental deletion, ransomware, filesystem corruption, electrical damage, or a bad command can affect the entire system.

Useful backups are separate, current, and tested.

NIST recommends planning, maintaining, and testing backups. Its guidance focuses on making sure backup files remain available and usable during recovery. Testing matters because a successful backup notification proves that a job ran. A restore proves that the data can come back.

For irreplaceable data, I want multiple copies and at least one copy away from the house. Fire, theft, flooding, and electrical damage do not respect the boundaries between servers sitting in the same rack.

The price of self-hosting includes that extra capacity.

Maintenance belongs in the decision

Open-source software can be free to download. Operation still consumes time.

Updates need to be reviewed and applied. Breaking changes need attention. Certificates expire. Storage fills. Databases need maintenance. Projects can lose maintainers. Hardware reaches the end of its useful life.

The work becomes easier when the system is documented. I want to know:

  • Where the service runs
  • Where its configuration lives
  • Which data needs to be backed up
  • How remote access works
  • How to restore it
  • How another person can turn it off safely

Documentation also reveals complexity. If a small service needs three pages of recovery instructions, its place in the homelab deserves another look.

Some services reward local operation

Home automation is a strong candidate because local control improves response time and resilience. Lights and sensors can continue working during an internet outage when the controller and device communication remain inside the home.

Media libraries also fit well. They involve large amounts of data, predictable local use, and few reasons to send every stream through an external provider. Network-wide tools such as DNS filtering can provide value to every device in the house with modest hardware.

Photo storage, file sync, and document management can be worthwhile when data control matters enough to support a serious backup plan.

Development environments, dashboards, monitoring tools, and experimental applications are excellent homelab workloads. They provide room to learn, and their failure usually remains manageable.

Some services demand specialist operations

Email has a low tolerance for mistakes. Deliverability depends on reputation, DNS configuration, spam controls, security, and the policies of other providers. A working mail server can still produce messages that never reach an inbox.

Public services with strict uptime requirements also require careful thought. A business-critical website, customer database, or public API may benefit from infrastructure with redundant power, networking, hardware, and on-call support.

Heavy compute can work well as rented capacity when the workload appears in short bursts. Owning hardware that remains idle most of the month can cost more in purchase price, electricity, cooling, and maintenance.

The choice can be hybrid. A service can run locally while encrypted backups live elsewhere. A public endpoint can use hosted infrastructure while private data stays at home. A cloud system can handle identity or email while local hardware handles storage and automation.

Self-host the responsibility you want

The best self-hosted service gives you control you value, teaches you something useful, and carries a maintenance cost you can sustain.

My checklist is straightforward:

  1. What data does it hold?
  2. What happens when it fails?
  3. Who depends on it?
  4. Can I restore it from a separate backup?
  5. Can I secure remote access?
  6. Will I still want to maintain it in two years?

Those questions remove a surprising number of services from the rack. They also make the services that remain much better.

Self-hosting gives ownership of the system and ownership of every future problem. That combination is exactly what makes it valuable.