Cloud Vendor Lock-In Explained
Vendor lock-in is the situation where switching cloud providers becomes prohibitively expensive or technically complex. In 2026, after high-profile incidents like Heroku's price hikes and the Railway / GCP outage, lock-in has become a board-level conversation. Here is what it means, why it matters, and how to architect against it.
On-Premise
Definition
What is vendor lock-in?
A dependency on a specific cloud provider's proprietary services, APIs, or pricing such that switching to another provider would require significant rework, migration cost, or downtime.
Three flavors
Technical lock-in
Your code uses provider-specific APIs (AWS Lambda, Cloud Functions, Firebase). Switching means rewriting.
Data lock-in
Your data lives in a proprietary format (Firestore, DynamoDB, BigQuery). Egress fees and conversion make migration expensive.
Pricing lock-in
Multi-year reserved instances or enterprise discounts that disappear the moment you leave.
Real examples 2024-2026
Lock-in in the wild
Four recent examples teams paid for in real money and downtime.
Heroku price hikes
Salesforce raised prices and removed the free tier. Customers locked into buildpacks, the add-on ecosystem and the CLI faced painful migrations. Cost: $50-500K for mid-market.
Railway / GCP outage
Railway customers learned that "multi-region" inside the same GCP project is not real redundancy. When Google blocked Railway, every customer went down regardless of region.
Vercel bandwidth pricing
Vercel's edge functions and image optimization are tightly coupled to their platform. Apps using these features cannot move without significant rework.
Firebase Firestore
Firestore's NoSQL document model is GCP-specific. Migration to Supabase / Appwrite requires schema rewriting and client SDK changes.
Hidden costs
The cost of lock-in goes beyond migration
Reduced bargaining power
The provider knows you cannot easily leave. Pricing renegotiations end badly when you have no off-ramp.
Bill shocks without recourse
Pricing changes hit you without an off-ramp. Heroku's 2022 price increase is the textbook case.
Tied to provider's roadmap
If they remove a feature, you scramble. If they shift focus, your investment depreciates.
Compliance constraints
If jurisdiction requires data sovereignty and your provider does not match, you have an emergency migration on your hands.
Architecture principles
6 principles to architect against lock-in
Principle 1
Use portable abstractions
Docker / OCI containers, PostgreSQL / MySQL / Redis, REST / GraphQL, S3 API. Open standards portable to any cloud.
Principle 2
Own your data layer
Keep databases on VMs you control. Schedule regular exports outside the provider. Use open formats (Parquet, CSV, SQL dumps).
Principle 3
Multi-cloud capability
Have the ability to deploy to a second cloud in under 1 week, even if you don't run multi-cloud daily. Use Terraform / IaC for portability.
Principle 4
Limit proprietary serverless
Lambda, Cloud Functions, Azure Functions bind tightly. If you use serverless, abstract business logic so the function is a thin wrapper.
Principle 5
Negotiate exit terms
Data egress fees waived during termination. Standard formats for data export. Reasonable contract end dates in enterprise contracts.
Principle 6
Prefer open-source software
Run open-source apps (PostgreSQL, n8n, Supabase) instead of proprietary SaaS. The software itself stays portable, so you can self-host it on any cloud.
Elestio's lock-in posture
Why Elestio is low lock-in
Dedicated VMs you can snapshot
Your apps run on VMs you can snapshot and migrate. No shared multi-tenant abstraction blocking exit.
9 clouds + BYO VM
Switch cloud providers without leaving Elestio. Or leave Elestio entirely while keeping your data and apps.
No Elestio fork of apps
PostgreSQL is PostgreSQL. n8n is n8n. We run the standard upstream, not a proprietary fork.
Migration in 1-2 hours
Take a backup, restore on another Linux server, switch DNS. Standard tooling, no special steps.
Deploy without lock-in
Free trial on Elestio. Dedicated VMs, open-source apps, 9 cloud providers.
Reviews
Trusted by 10,000+ Developers Worldwide
Real reviews from real users on Trustpilot.
"I'm in the IT industry for over 25 years and Elestio stands out in many ways. The managed services are top-notch, support is incredibly fast, and the platform just works. Couldn't be better!"
FAQ
Frequently Asked Questions
-
Is some level of lock-in unavoidable?
Yes. Every provider has some proprietary aspect. The goal is not zero lock-in but manageable lock-in: you can leave in days, not months, without rewriting half your codebase.
-
Which hosting platforms lock you in the most?
Single-cloud PaaS lock you in hardest: Railway runs only on Google Cloud, Render and Vercel tie you to their runtime and pricing, and Heroku to its buildpacks and dynos. Leaving means rebuilding. Elestio keeps you on standard open-source apps and dedicated VMs across 9 clouds, so you can move in days.
-
Is Elestio itself lock-in?
Low. Elestio runs standard open-source apps on dedicated VMs. You can leave by taking a backup and restoring on any Linux server. The Elestio-specific layer is just the management dashboard, not the data or app layer.
-
How long should a cloud migration take if I am not locked in?
For a typical mid-market workload (web app + database + storage), 1-7 days from decision to fully cut over. Larger workloads scale accordingly.
-
Is multi-cloud the only way to avoid lock-in?
No. Multi-cloud capability (the ability to switch quickly) is the goal. You can be on one cloud most of the time but architect so that switching is fast. That is Elestio's approach.
Manage lock-in before it manages you
Elestio: dedicated VMs, 9 cloud providers, open-source apps, full portability. Free trial.
Start free trial