The Exit Test: Can You Actually Leave Your Cloud Platform?
Every cloud platform is easy to enter. The real question is whether you can leave. We wrote a 7-step script that exports your data, deletes the cloud instance, runs the service locally, and verifies nothing was lost — using nothing but curl, jq, and Docker.
Every platform makes it easy to sign up. The homepage has a big button. The docs have a quickstart. You're up in minutes. Nobody advertises how hard it is to leave. That asymmetry is by design. Once your data lives inside a platform's proprietary storage format, behind a vendor SDK, accessible only through an authenticated export endpoint that requires contacting support — the cost of leaving gets very high. Not always maliciously. Sometimes it's just the natural gravity of a system that was never designed with exit in mind. The way to test this isn't to read the terms of service. It's to actually try to leave. Export your data. Delete the instance. Run the software somewhere else. Verify nothing was lost. We did that. Here's what happened.
Why Lock-In Is Usually Invisible
Most cloud lock-in doesn't announce itself. You don't get a notification saying "by the way, your data is now in a format only we can read." It accumulates quietly. You use the platform's managed database. It works great — until you discover the backup format requires their proprietary restore tool. You store files in their object storage with custom metadata tags that don't map to S3. You run queries against their analytics service and slowly the report schemas become load-bearing infrastructure. By the time you notice the lock-in, you're already inside it. The standard counterargument is: just use open standards. But "open standards" as a checkbox means very little if the software running on the platform is proprietary. The API might be open but the running system isn't. You can export JSON but you can't reproduce the exact version of the database, with its exact configuration, somewhere else. Open source changes this. If the software running on the platform is exactly the upstream package — unmodified, same Docker image, same configuration options — then portability is not a promise. It's provable.
The Exit Test
I want to propose a concrete test. Not "is this platform open source friendly?" Not "can you theoretically export data?" The question is sharper than that: Can you actually leave? Today. In less than 30 minutes. With no support ticket, no migration service, no data loss? The test has seven steps: (1) Create a service instance on the platform. (2) Write real data to it using standard APIs. (3) Export everything — raw, via HTTP, no SDK. (4) Delete the cloud instance. (5) Run the exact same software locally with Docker. (6) Import the exported data. (7) Verify it's identical. If all seven steps work — if the data you wrote on the platform is byte-for-byte the same data you're now reading locally — you're not locked in. We ran this test on Eyevinn Open Source Cloud with CouchDB. The script is at https://gist.github.com/birme/00bbb4260567552687e73f11f8cebc1a. The tools used: curl, jq, docker. That's it. No vendor SDK. No proprietary export format. No support ticket. It works.
Why CouchDB Is a Good Test Case
CouchDB is a reasonable stress test for this because it's a document store with its own HTTP API. It doesn't use the ubiquitous Postgres wire protocol. If you're running something proprietary dressed up as CouchDB, the standard HTTP API calls would either fail or return data you couldn't load into a real CouchDB instance. The script writes five documents using plain PUT requests against the CouchDB HTTP API — the same API you'd use against any CouchDB, anywhere. It exports using _all_docs?include_docs=true, a standard CouchDB endpoint that returns everything as JSON. It imports using _bulk_docs, another standard endpoint. No part of this touches any OSC-specific API after the instance is provisioned. The CouchDB instance on OSC speaks the same protocol as the CouchDB running locally on port 5984 in a Docker container. They're the same software, unmodified, just running in different places. The verification at the end compares document contents. They match.
Open Source as Insurance, Not Philosophy
At OSC, every service is unmodified open source software. Postgres is upstream Postgres. Valkey is the upstream Redis fork. MinIO is MinIO. CouchDB is CouchDB. We don't fork them, we don't add proprietary extensions, we don't wrap them in a custom API layer. This isn't a philosophical position. It's a practical design decision with a specific goal: your infrastructure should be portable. "Portable" means something specific. It means you can take the data you've written, run docker run couchdb:3 on a laptop, load that data in, and have a working system. It means you're not dependent on OSC's continued existence, our pricing, or our business decisions. You can move to AWS, to your own datacenter, to another provider running the same open source stack. The exit test is how we verify that claim is real and not just marketing copy. We're not asking you to take our word for it. The script is public. Run it yourself.
The Practical Argument for Portability
If you're making infrastructure decisions for a team or a company, portability matters beyond the philosophical. You want to be able to negotiate with vendors from a position of genuine optionality. If leaving costs six months of migration work, you don't have leverage — you have a hostage situation with better UX. You want to protect against platform risk. Startups get acquired. Pricing changes. Services get deprecated. The cloud provider that's right for you today might not exist in three years. If your stack is open source, that risk is dramatically reduced — you can move. And increasingly, with agents making infrastructure decisions faster than humans can review them, you want to know that what the agent provisioned is something you could reproduce elsewhere. If an AI agent provisions a dozen services in an afternoon and half of them are proprietary, you've accumulated a significant lock-in position without consciously choosing it. Open source — actually open source, running unmodified — is the answer to all three of those concerns. The exit test is just how you verify the answer is real.
Frequently Asked Questions
Is this just CouchDB, or does OSC do this for all services?
The exit test script uses CouchDB as an example, but the principle applies across the platform. Every service on OSC is unmodified open source software. Postgres data can be exported with pg_dump and imported with pg_restore into any Postgres instance anywhere. MinIO data follows the S3 API standard. Valkey data can be exported with standard Redis commands. The pattern is the same: standard export, docker run, import, verify.
What if I need to keep running on OSC while I am evaluating alternatives? Is there a way to mirror data?
Yes. Because both the cloud instance and a local instance speak the same protocol, you can run them side by side. CouchDB has built-in replication. Postgres has logical replication. You are not doing a one-time migration — you can keep both in sync while you make the switch at your own pace.
This works for simple examples. Does it scale to a real production database?
The script uses five documents to keep it readable, but the export mechanism — _all_docs?include_docs=true for smaller datasets, or CouchDB's replication API for larger ones — is the same at any scale. The key insight is that you are using the database's own native export capabilities, not a platform-specific tool. For large production datasets, you would want a streaming export approach rather than a single HTTP call, but the portability guarantee holds.
Why does OSC use unmodified open source instead of managed forks with extra features?
Managed forks can add useful features, but they also add a lock-in surface. Every proprietary extension you depend on is one more thing you cannot reproduce elsewhere. We made a deliberate choice to offer the upstream software and let users decide which extensions, if any, they want to add themselves. The tradeoff is that we sometimes cannot offer features that require forking. We think the portability guarantee is worth more than the additional features.
Related Posts
Your Vibe-Coded App Deserves Better Than a Credit Tax
Credit-based AI builders charge per generation. When free tiers expire, real costs emerge. Deploy your vibe-coded app on real infrastructure, no credits, no counter.
6 AI Agents. 14 Services. 36 Hours.
How Streaming Tech TV+ went from concept to fully deployed streaming platform — with zero manual infrastructure. A case study in what happens when AI agents not only write the code, but operate the infrastructure too.
Vibe Coding Meets Open Source Deployment
AI writes the code. But where does it run? Vibe coding tools generate applications in minutes — yet deployment remains the gap. Open Source Cloud bridges that gap with zero lock-in infrastructure that AI agents can provision directly.