Going Commando: Running Public Website on Server in a Closet

The blog you’re reading is hosted on a server that sits on the floor in a closet in our condo in San Francisco. You’re accessing it over my very pedestrian home internet connection (bizarrely, getting fast residential internet in San Francisco is hard). I don’t have a static IP address so DNS is resolved using Dynamic DNS (DDNS) and DNS records are updated whenever my ISP changes the external IP address. There’s no redundancy and power for the server has no battery backup. Some software update tasks are automated, but many I only do whenever I happen to log onto the server for one reason or another. There’s no fancy container orchestration, just Docker containers running with the --restart unless-stopped flag.

By all rights, uptime and availability for the blog should be horrendous. It should have been pwned by script kiddies many times over. The assorted software pieces should error or fail regularly.

But that’s not what actually happens. Uptime for the server is typically measured in months with the only interruptions happening when I flip the breaker to do electrical work on the house, or similar.

I reflected on this because of 37signals’ recent ONCE announcement where you buy and pay for their software once (as it were) and own a license to use it on your own hardware in perpetuity, instead of buying a subscription for a SaaS-hosted version. Some of the pushback on Twitter emphasized how SaaS is a better model because self-hosting software exposed to the public internet is uniquely difficult and scary. I’m not saying it’s easy, but I also don’t think it’s actually that hard and I can see how it’s a refreshing alternative to straight-jacket SaaS models with ever-increasing subscription prices.