Why I Started Self-Hosting Things

Deploying software has honestly gotten ridiculously easy, and that's a good thing. I love Vercel. I love managed databases. I love being able to connect a GitHub repo, press approximately three buttons and suddenly something I built on my laptop exists on the internet. I'm not interested in going backwards just for the sake of suffering.

Magic I'm responsible for

At some point I realized that a lot of the infrastructure I was using felt like magic. And I don't like magic that I'm responsible for. I knew how to deploy applications, but I didn't really understand deployment. I knew how to create a database, but a company was handling most of the annoying parts for me.

• Networking? Abstracted.
• TLS? Handled.
• Processes? Handled.
• Storage? Mostly handled.
• Monitoring? Here's a dashboard.
• Scaling? Click this.

That's the entire point of these platforms. They're supposed to remove complexity. But I kept getting more interested in the complexity they were removing.

So I bought a server

Not because it was the most efficient solution. Honestly, managed cloud services are probably the better answer for a lot of the things I do. I bought one because I wanted to understand what happens when all those nice abstractions disappear.

Very quickly, things I barely thought about became my problem: networking, SSH, users, permissions, ports, firewalls, storage, processes, services, VPNs, logs, DNS, reverse proxies, certificates, backups. And that beautiful moment where something works perfectly on your local network and absolutely nowhere else. Fun.

Your app is not just your code

It changed how I think about software. You start realizing that your application isn't just the code you wrote. Your code is sitting inside layers of other systems. Your process needs somewhere to run. That machine needs an operating system, and that operating system needs networking. Your traffic needs to reach the right process. Your process needs credentials. Your data needs somewhere to live. Something needs to restart everything when it inevitably crashes, and something needs to tell you that it crashed. And somebody needs to secure the whole thing.

Congratulations. That somebody is now you.

Breaking things was the useful part

I broke things. A lot. But weirdly, that was probably the useful part. When everything is managed for you, failures can feel like random error messages. When you build more of the stack yourself, you start developing a mental model of what's actually happening underneath.

Now when something doesn't connect, I start thinking about where in the chain the failure could be:

• Is the service running?
• Is it listening on the correct interface?
• Is the port exposed?
• Is the firewall blocking it?
• Can DNS resolve it?
• Is the proxy forwarding correctly?
• Is TLS failing?

That's a completely different way of debugging from “why doesn't this URL work?” And that mental model carries over even when I go back to managed cloud platforms. That's probably the biggest thing self-hosting taught me.

The inconvenient version teaches you why the convenient one exists

I didn't do it because I believe everything should be self-hosted. I definitely don't. I did it because sometimes using the inconvenient version of a technology teaches you why the convenient version exists.

There's value in that, especially now. AI is making it incredibly easy to skip layers of understanding. You can tell an agent “deploy this,” and sometimes it just does it, which is amazing. But I've been trying to make sure that as the tools around me become easier, my understanding underneath them doesn't become shallower. I want to know what the agent is doing, at least enough that when it fails, I'm not completely helpless.

That's also why I like building things slightly outside my comfort zone. Not because every project needs to become a massive infrastructure exercise, but because sometimes I deliberately choose the longer route when I know there's something inside it I haven't learned yet.

A little machine running your stuff

There's something satisfying about it too. No massive cloud console. No ten different managed products. Just: there's my server, there's my application, there's the process, there are the logs, and there's the thing I broke yesterday. Beautiful.

Will I deploy every startup I ever build onto a computer in my house? Absolutely not. Please don't hold me to that. But the next time I deploy something to a managed platform in three clicks, I understand a little more about what those three clicks are saving me from. And to me, that was worth doing it the hard way.