Vendor lock-in is one of those problems that rarely shows up on day one. In fact, it often looks like the right decision at the beginning: fewer vendors, one dashboard, simple billing, less mental overhead. It feels efficient—until it isn’t.
Looking back, one of the biggest lessons I’ve learned is that vendor lock-in doesn’t usually come from bad choices. It comes from convenient ones.
“Unlimited” Only Exists Until You Matter
Or until Enshittification catches up with you!
Many providers offer incredibly powerful systems, and there’s nothing wrong with using them. Cloudflare is a good example. Their tooling for scaling, caching, and traffic control is genuinely excellent. The problem begins when you build your entire stack around proprietary APIs and internal mechanisms that only they control.
At that point, you’re no longer just a customer—you’re dependent.
As long as your usage fits neatly into their business model, everything runs smoothly. But once you grow, change, or simply become inconvenient, the rules shift. “Unlimited” suddenly has limits. Vague technical issues appear. And more often than not, the solution turns out to be an upgrade that costs significantly more—sometimes 10x or 20x—without actually solving your underlying needs.
The hard lesson here: if leaving a provider feels impossible, you’re already locked in.
Bundling Services Creates Silent Single Points of Failure
This is where I made a classic mistake.
I originally used Namecheap for domain registration—and over time, also for hosting and email. On paper, this looked clean and efficient. In practice, it created a dependency I didn’t fully appreciate at the time.
By bundling everything under one provider, I handed them a single switch that could take down my entire online presence. Domains, websites, email—gone in one move if something ever went wrong. Whether that problem is legitimate, accidental, or policy-driven doesn’t really matter. The risk is the same.
That’s the moment I realized that vendor lock-in isn’t just technical—it’s operational and existential.
Portability Is More Valuable Than Optimization
The goal isn’t to avoid big providers. It’s to avoid being trapped by them.
I still use Amazon Web Services, for example. Compute and S3 are solid, mature products—but they can become expensive fast if you’re not careful. The upside is that compute workloads are portable, and S3 is no longer unique to AWS. Many providers now offer S3-compatible storage, which makes diversification far easier than it used to be.
In my own setup:
-
Some workloads run on AWS
-
Most production systems run on DigitalOcean because they’re often faster and cheaper for my use cases
-
Storage is split based on access patterns, not loyalty
This flexibility means I can choose the best tool for each job—and leave if I need to.
Use Providers for What They’re Best At
A good example of this is storage.
For long-term, rarely accessed data, AWS Glacier Instant Retrieval is nearly unbeatable on price. Storing a terabyte for a few dollars a month is hard to argue with. Yes, retrieval can be expensive—but if you only need to pull data occasionally, that trade-off makes sense. Paying $10 to retrieve a critical 10 GB configuration once in a blue moon is fair.
For real-time access, I prefer DigitalOcean’s object storage. It’s better integrated, faster due to same-datacenter access, and easier to work with operationally. And if something ever goes wrong, I’m not stuck—I can move to another S3-compatible provider with minimal changes: update endpoints, rotate credentials, adjust DNS, done.
That’s the key insight: design systems so that switching providers is boring, not terrifying.
Domains Are the Weakest Link—Treat Them Accordingly
Domains are different. A domain name is unique. There is no redundancy, no fallback, no hot spare. It’s the ultimate single point of failure.
That’s why I decided to move away from Namecheap—not because their service is bad, but because there’s a consistent pattern of reports across customer-feedback platforms about accounts being locked, sometimes without clear explanations. Whether those cases are justified or not is almost irrelevant. The risk alone is enough to rethink the setup.
I’m now slowly transferring domains to Porkbun. It’s not a perfect solution, and being a US-based company means there’s always potential for regulatory or policy-related surprises down the line. But diversification isn’t about eliminating risk—it’s about reducing blast radius.
Separation Is a Strategy, Not Overengineering
This is where EthernetServers comes in.
I’ve used EthernetServers for years, and the experience has been consistently positive. Support is responsive, practical, and refreshingly free of unnecessary bureaucracy. Because of that trust, I decided to move hosting that was incorrectly bundled under Namecheap over to EthernetServers and separate concerns properly.
Registrar here. Hosting there. Compute somewhere else. Storage split by access pattern.
No single vendor holds all the keys anymore.
The biggest lesson I’ve learned is this:
Vendor lock-in rarely breaks systems first—it breaks options.
By choosing portability over convenience and separation over bundling, I’ve traded a bit of simplicity for a lot of resilience. And for a personal stack—or any system you care about long-term—that’s a trade I’m happy to make.
