Why Self-Hosting Still Matters
The argument for owning your infrastructure in 2026: privacy, durability, cost, and the simple joy of running your own hardware.
Every few years, someone announces the death of self-hosting. The argument is always the same: cloud is cheaper, easier, and more reliable. There is no reason to run your own hardware. Buy a managed service. Move on.
This argument has been wrong for fifteen years, and it is still wrong in 2026. Here is why.
The economic argument is overstated#
Cloud is cheap for the first 100GB. Cloud is cheap for the first 10 users. Cloud is cheap until you have a steady state of petabytes, hundreds of users, and a few services that run 24/7. Then the math changes.
A small home server — a refurbished mini-PC with 64GB of RAM and a Ryzen 7 — costs ₹35,000–50,000. It draws 30–50W at idle, which is roughly ₹500/month in electricity in India. It can run an entire household’s worth of services indefinitely.
A comparable cloud footprint — a small VM, a managed database, a managed object store, a managed Kubernetes cluster — costs ₹5,000–15,000/month. The breakeven point is roughly 6–12 months. After that, self-hosting wins on raw cost, and it keeps winning.
The cloud is a subscription. Self-hosting is an asset. The economics of these two things are fundamentally different, and they diverge in your favour the longer you stay on the hardware.
The privacy argument is real#
The cloud is someone else’s computer. Every byte you put in it is, in some sense, accessible to the operator. The operator may not look at it. The operator may have strong internal controls. The operator may be philosophically aligned with your interests.
But the operator can look at it, and so can anyone with a subpoena, a warrant, or a national security letter. The list of companies that have been compelled to hand over user data is long. The list of companies that have successfully resisted is short.
Self-hosting puts the data on hardware you control, in a jurisdiction you control, with legal protections that you understand. This is not a guarantee of privacy — your hardware can be seized, your data can be subpoenaed — but it is a meaningful improvement over the default.
For most of us, the most sensitive data on our servers is not state secrets. It is family photos, personal calendars, and the metadata of a private life. The cloud is a reasonable place for some of that. It is not a reasonable place for all of it.
The durability argument is underrated#
The cloud is reliable. The cloud is not durable in the way that your own files are.
Every few years, a cloud provider has a regional outage that takes out half the internet. Every few years, a SaaS company shuts down a service that people relied on. Every few years, a price increase makes a service unaffordable for the people who built their lives around it.
Self-hosted services do not have these failure modes. They run as long as the hardware runs, and the hardware runs for a decade if you treat it well. The data is yours, in formats you can read with open-source tools, on devices you can replace.
This is not a hypothetical. I have a folder of family photos that has been on spinning rust since 2009, in formats I can still read in 2026. I have email archives from 2005 in mbox files. I have a git repository that has been continuously backed up across four different machines.
The cloud is a service. Self-hosting is an archive. These are different products, and they serve different needs.
The capability argument is the real one#
The reason most people self-host is not the cost, and not the privacy, and not the durability. It is the capability.
When you run your own services, you can:
- Add features that the cloud provider decided weren’t worth building.
- Modify behaviour that the cloud provider decided you couldn’t change.
- Integrate services in ways that the cloud provider didn’t anticipate.
- Move data between systems without paying a tax.
- Debug problems at the network level when something goes wrong.
You also learn things. You learn how DNS works, how certificates work, how routing works, how firewalls work. You learn how to read a packet capture. You learn how to set up a database and tune its performance. You learn how to recover from a disk failure.
These are not just skills for self-hosting. They are the skills that the rest of your technology career is built on. Every cloud engineer who can debug a real outage learned it by running their own infrastructure first.
The right way to self-host#
If you are convinced, here is the short version of how to start.
Start small. A Raspberry Pi or an old laptop is enough to run a Pi-hole, a password manager, and a personal wiki. Get those working first. Do not try to migrate your entire digital life in a weekend.
Pick boring software. Nextcloud for files. Jellyfin for media. Vaultwarden for passwords. FreshRSS for feeds. These are mature, well-documented, and have been around long enough that the upgrade path is well-trodden.
Automate from day one. Use Ansible, or NixOS, or whatever you are comfortable with. If you have to do anything twice, you should be writing a script for it.
Back up. The 3-2-1 rule: three copies, on two different media, with one offsite. The offsite copy can be a friend’s house. It can be a cloud bucket that you only use for backups. The point is that a single failure should not take out your data.
Document. Future you will not remember why this server exists. Write it down. Keep a running list of every service, what it does, and how to rebuild it from scratch.
Self-hosting is not a destination. It is a practice. The interesting part is the gradual accumulation of small, boring, reliable systems that you understand and that work for you.
The cloud is a wonderful tool. It is not a replacement for understanding how your own infrastructure works. The two can coexist. Mine do.