I think about this question a lot. If AWS exists and works really well, why do I still buy hard drives, RAM, and servers for my house? On paper, it doesn’t always make sense. Hardware costs money. Electricity costs money. Drives fail. You have to manage backups. If you compare that to spinning up an EC2 instance in a few clicks, the cloud looks cleaner and more rational.
But the comparison isn’t actually apples to apples.
For me, self-hosting and AWS solve two very different problems.
The biggest advantage of self-hosting isn’t cost savings. It’s freedom to make mistakes.
In the cloud, mistakes scale financially. If you misconfigure autoscaling, forget to shut something down, accidentally expose a service that generates heavy traffic, or move a lot of data in and out of a region, the bill reflects it. AWS doesn’t care whether you were experimenting or running production — usage is usage.
At home, the blast radius is naturally capped. Your hardware is finite. Your internet bandwidth is finite. Your risk is bounded by what you physically own. You can deploy something poorly, rewrite it three times, overprovision it, or experiment with a terrible architecture and the worst case is usually inconvenience — not a surprise five-figure bill.
That changes how you build.
When I’m experimenting — whether it’s spinning up internal apps, testing AI agents, running Ollama endpoints, or wiring together services in questionable ways — I want room to move fast. I want to be able to give a virtual machine full access to a browser, let an agent run in what I’d call a “dangerous mode,” and see what happens. I can isolate it on a VM, let it do what it needs to do, and not worry about cost per request, cost per gigabyte, or cost per mistake.
Could I do that in AWS? Of course. But now I’m thinking about instance types, data transfer, storage growth, and whether something I forgot to shut down will quietly run for weeks. The mental overhead is different.
That doesn’t mean I don’t value AWS. I absolutely do.
AWS gives me things my home lab can’t easily provide. It gives me managed databases backed by Amazon’s infrastructure. It gives me load balancing, high availability, and geographic redundancy. If I need something to be reliably reachable, or I want a clean production environment with fewer moving parts under my control, the cloud is the right tool.
There’s also a psychological shift when something runs in AWS. I treat it differently. I architect more intentionally. I think about uptime and durability. I assume other people might depend on it.
At home, I optimize for flexibility. In AWS, I optimize for reliability.
Another difference is experimentation versus distribution. At home, I can run things in cold or warm states, keep experimental services hanging around, try weird network topologies, or keep partially finished systems online just in case I want to revisit them. I’m not constantly cleaning up to control spend. The system exists for curiosity and iteration.
In AWS, I’m more selective. I deploy what needs to exist publicly, what needs stable DNS, what needs predictable uptime, or what benefits from managed services. I don’t treat it like a sandbox. I treat it like infrastructure.
So why both?
Because they balance each other.
Self-hosting gives me a bounded playground. It’s where I learn, experiment, and sometimes build things in less-than-perfect ways just to understand them better. AWS gives me scale, stability, and professional-grade infrastructure when something graduates from “experiment” to “service.”
It’s similar to the idea of dev and prod. Not everything deserves production-level infrastructure on day one. Some things need to be messy first. Some ideas need to survive experimentation before they earn the right to live in the cloud.
If I only used AWS, I’d experiment less freely. If I only self-hosted, I’d constantly be rebuilding things that managed services already solve well.
So I do both.
The home lab is where I learn and move fast. AWS is where I stabilize and scale. And having both keeps me honest — about risk, about cost, and about what actually deserves production-grade infrastructure.