What Happens to My App If the Platform Shuts Down
Platform shutdowns happen. Learn what happens to your app, how to prepare with backups and portable code, and recover in 48 hours instead of losing everything.
- Platform shutdowns happen: Heroku's enterprise shift and Builder.ai's 2024 collapse are recent examples
- Lock-in comes in four layers: data, code, integrations, and knowledge; understanding each determines your real exit cost
- Independent backups, standard integrations, and testing your recovery process are non-negotiable preparation steps
- Managed platforms (Ship, Railway) cost more but reduce ops burden; Hetzner + Coolify costs less but requires infrastructure expertise
- Your recovery path after shutdown is 1-48 hours if you prepared; weeks or total loss if you didn't
Your app is running. The platform works. But what if it stops? This isn't paranoia: platform shutdowns happen (Heroku's enterprise shift, Builder.ai's $450M collapse in 2024), and most developers only think about exit when it's too late. Here's what actually happens to your code, data, and running services when a platform dies or changes hands.
Why Platform Shutdown Matters (And How Often It Happens)
Platform risk is real. It's not hypothetical. You are evaluating deployment platforms right now, and portability is part of that decision. When a platform shuts down, gets acquired, or shifts strategy, your app stops running unless you move it. Fast.
Heroku's recent shift into maintenance mode is a clear example. Salesforce acquired Heroku in 2020, invested for five years, then signaled a transition away from consumer-focused hosting toward enterprise services. Users saw features deprecate, pricing change, and the roadmap narrow. Many didn't prepare. They scrambled.
Builder.ai, which raised $450 million to democratize app building with AI, collapsed in 2024 due to financial mismanagement. Apps built entirely on their platform with no independent export path got stuck. Founders had to rebuild from scratch or find alternative platforms. OVHcloud's 2021 data center fire in Strasbourg destroyed customer infrastructure and took weeks to recover. These aren't rare events. They're management risk you should account for.
Shutdowns fall into two categories: orderly and surprise. An orderly shutdown gives you 30-90 days notice, data export tools, and support staff to help you move. A surprise shutdown (bankruptcy, acquisition, data center failure) gives you hours or nothing. Your recovery depends on how prepared you are.
What Actually Happens in a Shutdown: Orderly vs. Surprise
When a platform shuts down, what exactly fails depends on the shutdown type. Orderly: you get notice and tools. Surprise: you get chaos and manual recovery. Understanding the difference changes how you prepare.
In an orderly shutdown, the platform operator announces closure 60-90 days out. They keep servers running throughout the transition. You can export your database, download your code, redirect your domain, and test your new deployment before the old one dies. Your users stay online. This is the best case, and it still requires preparation.
Heroku's enterprise transition was a soft version of this. They didn't shut down immediately. They shifted pricing, deprecated runtimes, and signaled the end of casual hosting. Teams that paid attention had months to plan. Teams that ignored the signal got hit with price increases or feature removal mid-project.
In a surprise shutdown (bankruptcy, data center failure, acquisition gone wrong), you get no notice. Your servers stop. Your database becomes inaccessible. If you don't have an independent backup, it's gone. Users see 502 errors. Revenue drops. You have hours to restore service or lose customers permanently. This is rare, but it's the scenario that keeps ops leads awake.
Acquisitions are a third scenario: the platform doesn't shut down, but it changes. Features disappear. Pricing doubles. The roadmap shifts to serve the acquirer's goals, not yours. Heroku Salesforce is exactly this. Acquired platforms often become worse over time as the owner optimizes for their own use case, not yours.
The Four Ways You're Locked In (And How Deep It Goes)
Vendor lock-in isn't one thing. It's four separate constraints that compound. Understand each one, and you'll know exactly what it costs to leave.
Data lock-in: Your database is on their infrastructure. Can you export it cleanly? Some platforms (Vercel with Supabase, Northflank with managed PostgreSQL) make exports straightforward. Others bundle the database so tightly that export requires manual SQL dumps and data validation. If you can't export your data, you can't move. Worse, if they shut down suddenly, your data is gone.
Code lock-in: Your code was written to run on their platform. Framework wrappers, deployment abstractions, proprietary APIs. When you export it, does it run on a different host? Railway-deployed apps are usually standard Docker. Vercel apps often depend on Vercel-specific Functions API. Heroku apps rely on Procfiles and the Buildpack abstraction. Moving code off Heroku is often painless; moving off a custom platform is a rewrite.
Integration lock-in: Your app relies on proprietary platform APIs. Logging, monitoring, secrets management, deployment webhooks. When you move, you have to rip out these integrations and replace them with standard alternatives (Datadog instead of platform logging, Stripe instead of platform billing). The more proprietary abstractions you built, the longer the migration. This is less about data loss and more about operational overhead.
Knowledge lock-in: If you built your app with a vibe-coding tool like Lovable, Base44, or Bolt, the generated code is yours legally, but it's often under-documented. The AI wrote it. You didn't. You understand the business logic but not the implementation details. When you export it, you have a codebase you only half-understand, running on infrastructure you didn't set up, with undocumented dependencies. This makes migrations slower and riskier.
All four layer up. If you hit all four simultaneously, a platform exit can cost weeks of engineering time. That's the real cost of vendor lock-in: not lost data, but lost development velocity at a critical moment.
Vibe-Coding Platforms and Portability: Lovable, Base44, Bolt
Vibe-coding tools generate your entire frontend and backend from natural-language prompts. You iterate with an AI co-pilot, not by writing code. This is fast. It's also the highest lock-in scenario because you didn't write the code, understand it, or test it independently.
Lovable (built on Supabase for data) lets you export your entire project as a codebase and redeploy it independently. The exported code is standard React + Node.js. This is good. But Lovable also handles your database and file storage through Supabase integration. If you want to move your database to a different provider (e.g., from Supabase to Amazon RDS), you have to migrate it yourself. See our guide on how to get your database out of Lovable Cloud for the exact steps.
Base44 and Bolt take different approaches. Both generate standard deployable code (usually Docker-ready), but neither offers first-class export tooling. You export by copying your git repo and deploying it yourself. The risk: you're getting code that was AI-generated and only tested on their infrastructure. Edge cases and environment-specific bugs might not surface until you deploy elsewhere.
The real portability question for vibe-coding: Can you export, and can you confidently run the exported code on a different platform? Lovable: yes, mostly. Base44 and Bolt: technically yes, but with higher risk. See our vibe-coding platform data export comparison for a detailed breakdown of each tool's export process and what you're responsible for after export.
Deployment Platforms Compared: Risk vs. Convenience
Deployment platform choice determines your exit cost. Each platform trades convenience for lock-in risk. Understand the tradeoffs.
Managed platforms (Ship, Railway, Northflank, Render, Heroku): You push code. They handle scaling, monitoring, database backups, SSL certificates. Cost is predictable. Failure rate is low (outages are rare). But lock-in is real. Your deployment config is platform-specific. Your database might be managed by them. Your environment variables live in their dashboard. Exit cost is 2-7 days of engineering work for a moderately complex app.
Ship specifically positions itself on portable architecture. Standard Docker, external database (your Supabase or Postgres), no proprietary APIs. This reduces lock-in. You can export your app and run it on Hetzner, DigitalOcean, or any Docker-capable host with minimal rework. The tradeoff: slightly higher upfront setup cost than Heroku (Heroku abstracts more away). But your portability is built-in from day one.
DIY + open-source PaaS (Hetzner + Coolify, or Hetzner + Dokploy): You rent a VPS (usually 4-12 euros/month) and deploy using open-source tools. Coolify has 59,300 GitHub stars and active maintainers. Dokploy has 26,000 stars and 6 million downloads. You get full control over everything: code, data, infrastructure, backups. No vendor lock-in because you own the whole stack. But you own the operations burden too. Database failures, backups, security patches, monitoring: you're responsible.
DIY is cheaper on paper (4-12 euros vs. $25-100/month on managed platforms) but higher risk. You must understand infrastructure. You must automate backups. You must monitor uptime. For a solo founder or a small team, this operational overhead is real. For a team with a devops person, it's trivial.
Vercel/Netlify (serverless front end + managed backend services): Deploy your frontend instantly. Scale to zero when not in use. Pricing is per-invocation or per-GB bandwidth. Lock-in is moderate on deployment but potentially high on services (if you use Vercel Functions, you're paying Vercel's execution costs, not compute costs). Backup and portability depend heavily on where your data lives. If your database is your own Supabase or AWS RDS, portability is fine. If it's bundled, it's tight.
For a vibe-coded app (Lovable deployed to Vercel, for example), you have two lock-in points: the vibe-coding tool and the deployment platform. Mitigation: export your code early, test it locally, make sure it runs on Docker. This de-risks both layers.
Protect Your App Today: A Practical Checklist
You don't need to leave your platform today. You need to be ready if it changes. Here's what to do now, in order of importance.
1. Export and test your code independently. This is non-negotiable. If you built on a vibe-coding platform, export your project. If you deployed to a managed platform, export your code and docker config. Deploy it locally. Run it. Make sure it works without the platform. This tells you exactly how portable you are. If it doesn't work, fix it now. Don't wait for a platform shutdown to learn this.
2. Keep your database separate and backed up. If your platform offers managed database, assume you can't access it after shutdown. Set up an independent backup: weekly SQL dumps to Amazon S3 or Google Cloud Storage or a separate host. Cost is negligible (usually less than $2/month). Recovery time if needed: hours instead of weeks. For vibe-coded apps using Supabase, this means downloading your Supabase database backups independently, not relying on Supabase's in-system backups alone.
3. Use standard integrations, not platform wrappers. If the platform offers a billing API, logging API, or auth service, check if you can swap it for a standard alternative. Stripe for payments. Auth0 or Firebase Auth for authentication. Datadog for logging. SendGrid for email. Standard tools cost more than some platform bundles, but they give you vendor independence. When you leave the platform, you leave with your integrations intact.
4. Document your database schema and environment config. This sounds boring. It saves you days if you need to migrate. Keep a SQL dump of your schema. Document which environment variables matter and what they do. If you built on Lovable or Base44, keep the generated code in version control and document any modifications you made. This is your recovery manual.
5. Register your domain with an independent registrar. If your platform owns your domain (some do), you are fully locked in. Move it to Namecheap, Porkbun, or Route 53 immediately. Same with email: if you use platform-managed email, move to Google Workspace or Fastmail. Independence costs $10-15/year. Dependence costs your whole business if the platform dies.
6. Test your full recovery process annually. Once a year, actually restore from backup. Redeploy to a different host. Verify everything works. This isn't paranoia. This is the difference between a recovered app and a lost app. Heroku users who ran this exercise in 2025 had migrations done in days. Users who didn't scrambled for weeks.
If the Shutdown Happens Tomorrow: Your Recovery Path
Preparation is the goal. But if it happens anyway, here's the sequence.
Hours 0-1: Confirm the outage. Is the platform actually down, or is it just your app? Check their status page. Check Twitter. If their servers are down, move to the next step. If it's just your app, you have time.
Hours 1-4: Restore from your independent backup. If you kept database backups in S3, download them now. Restore to your new host (Hetzner, Railway, Ship, wherever). This is why you tested the recovery process. You know how long this takes.
Hours 4-24: Redeploy your code. If you kept your code in independent version control (GitHub, GitLab), clone it. Build a Docker image. Push to your new host. Configure environment variables. Test locally first. Deploy. Verify critical paths (login, payment, data retrieval) work.
Hours 24-48: Update DNS to point to your new host. This is why you registered your domain independently. Change the A record or CNAME in your registrar (not in the platform). DNS propagates in minutes to hours. Users are back online.
Day 3+: Fix edge cases. Test the full feature set. Check for any data corruption or loss. Communicate with users. If you lost data, figure out how much. If you lose anything at all, the cost of that loss plus the 48 hours of downtime is your real exit cost.
For apps that took this seriously: 48 hours downtime, full recovery, minimal data loss. For apps that didn't: weeks of downtime, possible data loss, customer churn, rebuild from scratch.
Choosing the Right Platform: Ship and Alternatives
None of this means you should self-host everything on Hetzner. Managed platforms are valuable. They're just a tool, not a trap. The trap is not knowing your exit cost until it's too late.
Ship positions itself on portable infrastructure. You deploy standard Docker containers. You bring your own database (or use Ship's managed database with full export access). You don't pay for proprietary APIs or platform lock-in. Migration off Ship to Hetzner + Coolify or another host takes 1-2 days of engineering work instead of weeks. Cost is $25-200/month depending on your app size.
If you want to optimize purely for low cost and full control, Hetzner + Coolify (or Dokploy) is better. EUR 4-12/month for the host, $0 for the deployment tool. You own everything. You pay with your time. Backup and scaling are your responsibility. This works if you have someone on the team who understands infrastructure. It doesn't work if you're a solo founder.
Railway and Northflank (competitors in the Ship space) also offer portable deployments. They're more expensive than Hetzner but cheaper than Heroku. Exit cost is similar to Ship: 2-5 days to migrate. The choice between Ship, Railway, and Northflank comes down to pricing, UI preference, and how much you trust their long-term viability.
Vercel is better for pure frontend. Ship or Railway is better if you need backend. Hetzner + Coolify is better if you want full control and can afford the ops overhead.
For vibe-coded apps, the platform choice is critical. Ship's portable architecture means an exported Lovable app runs as cleanly there as anywhere else. Vercel is slightly cheaper but tighter lock-in. See how to avoid vibe-coding platform lock-in for specific guidance on choosing a deployment platform to pair with your AI tool.
Frequently Asked Questions
What happens to my app if I don't have a backup?
Your data is lost. Permanently. If the platform's database was your only copy and they shut down, you have no way to recover it. This is why independent backups (S3, Backblaze, another host) matter more than anything else. Cost: $1-5/month. Regret if you don't have it: immeasurable.
Can I move my app from Heroku to Ship or Railway?
Yes, usually in 2-7 days depending on complexity. Export your database. Export your code. Make sure it runs locally. Push to the new platform. The longer your app has existed on Heroku, the more platform-specific stuff you might have built (Procfiles, buildpacks, Heroku-specific config). That takes time to unwind. If your app is a recent export from Lovable, this is faster.
Are managed platforms like Ship worth the cost if I can self-host on Hetzner?
Depends on your team. If you have someone who understands infrastructure, Hetzner + Coolify saves money ($5-15/month vs. $50-200/month). If you don't, managed platforms save time. Managed platforms cost money because they absorb ops work. That's not a trap, it's a tradeoff. For a solo founder or a small team, that tradeoff is worth $50-100/month. For a team with a devops engineer, it's not.
What if I built on Lovable and want to move off?
Export your project from Lovable. It downloads as a git repo with your full source code. Review the code. Test it locally. Deploy it to your new platform (Ship, Railway, Hetzner, wherever). The main work is migrating your database (if Lovable was managing it) and reconfiguring your integrations. See how to move your app off Lovable for step-by-step instructions.
How often do platforms actually shut down?
Rare but not unheard of. Heroku's shift to enterprise happened over 2 years, not overnight. Builder.ai collapsed suddenly in 2024. OVHcloud's fire was an infrastructure failure, not a business failure. The real risk isn't shutdown; it's changes you can't control (pricing, features, roadmap). Preparation for shutdown also protects you against these changes.
Do I need to worry about this for a side project or MVP?
No. If your app is an experiment and you're okay losing it, don't over-invest in backup and portability. If it makes money or has users who depend on it, yes. The line is: would you care if this app disappeared tomorrow? If yes, you need backups and portability. If no, don't.
The Bottom Line
Platform shutdowns are rare. Platform changes are not. Understanding your exit cost (data, code, integrations, ops overhead) lets you make an informed choice between convenience (managed platforms) and control (DIY hosting). If you're evaluating platforms right now, test your portability before you launch. Export your code. Run your database independently. Verify you can move if you need to. That exercise tells you more about a platform's lock-in risk than any marketing claim.
If you want a platform that's optimized for portability from day one, explore Ship's portable deployment architecture and see if it fits your workflow.