Building My Self-Hosting Stack on .self Domains After 379 HN Points

Three weeks ago, I was refreshing a Hacker News thread like my next project depended on it. The .self TLD announcement had hit 379 points, and buried in the comments was a discussion I couldn't shake: developers losing access to their deployed applications overnight, not from technical failures, but from platform policy changes. I realized I'd been building on borrowed land for years.

The thread wasn't just about domain names. It was about ownership in an era where "the cloud" means someone else's computer, and someone else's rules. I'd accumulated a portfolio of side projects scattered across Vercel, Railway, and GitHub Pages — all functional, all vulnerable to decisions I had no control over.

The Vulnerability Audit

I spent the weekend mapping my dependencies. The picture wasn't pretty. My personal site lived on Vercel's infrastructure. My experiment tracking app ran on Railway. Even my static documentation sites relied on GitHub's goodwill and Cloudflare's DNS.

Each platform offered convenience, but at what cost? I found ToS clauses I'd never read, payment processing restrictions I'd never considered, and content policies that could theoretically flag my harmless developer tools. The code was mine, but the runtime wasn't.

The breaking point came from a comment thread about a developer who'd built a SaaS on modern platforms, only to wake up to suspension notices across multiple services simultaneously. A false positive in one platform's automated moderation had cascaded through their entire stack. Months of work, inaccessible.

I decided to migrate everything to .self domains, starting with moygulati.self.

Building True Independence

The technical challenges hit immediately. Self-hosting DNS means managing your own nameservers, which sounds straightforward until you're debugging propagation issues at 2 AM. I chose a hybrid approach: a dedicated server at home for development and testing, with a VPS backup for production workloads.

The hardware decisions forced me to think differently about architecture. No more infinite scaling assumptions. No more "just add another Lambda function" solutions. Every service I built now had to justify its resource footprint on actual hardware I was paying for and maintaining.

Setting up the deployment pipeline took longer than expected. Without GitHub Actions or Vercel's build systems, I had to construct everything from scratch. Docker containers, reverse proxies, SSL certificate automation — infrastructure work I'd been outsourcing for years.

The email server proved the most educational. Running your own mail infrastructure in 2024 means fighting spam filters, maintaining reputation scores, and keeping up with authentication protocols that major providers change regularly. I'm still working through delivery issues with Gmail.

Cost and Complexity Realities

Three months in, the numbers are mixed. My monthly platform fees dropped from around $200 to roughly $120 in server costs. But that doesn't account for the time investment — hours spent on maintenance tasks that Vercel handled automatically, troubleshooting network issues that AWS would have abstracted away.

The backup strategy alone required more planning than my previous setup. Platform providers offered redundancy I'd taken for granted. Now I'm running my own replication scripts, monitoring disk health, and maintaining offsite copies of everything.

Performance took a hit initially. My home server couldn't match Vercel's edge network, so I had to get creative with caching strategies and content delivery. Loading times for global users increased noticeably until I implemented a CDN layer — which introduced another dependency I was trying to eliminate.

What I'm Learning About "Self"

The .self domain sits in my browser's address bar, but I'm discovering that true independence is more complex than I anticipated. I still depend on my ISP, my VPS provider, the DNS root servers, and dozens of open-source projects maintained by volunteers.

What's changed is the locus of control. When something breaks, I can fix it. When performance degrades, I can optimize it. When policies change, they're my policies. The trade-off is responsibility — every outage, every security vulnerability, every performance bottleneck is mine to solve.

I'm also building differently. Without the safety net of infinite cloud resources, I write more efficient code. Without platform abstractions, I understand my stack more deeply. The constraints are teaching me things that abundant resources had obscured.

The Bigger Questions

Six weeks into this migration, I'm questioning whether I'm moving toward genuine independence or just creating a more sophisticated form of dependence. The internet remains fundamentally interconnected — my self-hosted services still rely on infrastructure I don't control.

But there's something valuable in the exercise itself. Building on .self domains forces you to confront the full cost of running software. Every service, every dependency, every architectural decision becomes explicit rather than assumed.

I'm not sure if this represents the future of development or an expensive form of nostalgia. What I do know is that my applications feel more mine now, in ways I didn't expect when I first saw that Hacker News thread.