Bubble allows you to export your app. Using the Bubble MCP (beta), an AI agent can read your app's design and functionality and recreate it in code. This is effective, but doesn't guarantee perfect fidelity. Your app data can be exported directly from the Bubble editor. With a code version of your app and its data, you can then continue building and hosting your app on another platform.

The process gives you a strong starting point, not a finished app. Bubble takes care of a lot behind the scenes, from hosting and security to user accounts and backups. Once you move your app, each of those becomes something you set up and run yourself. This article walks through what that involves, so you can plan the move, or decide whether it's the right move for you.

How it works

The agent connects to your app through the Bubble MCP and reads what's in it: your data types and fields, option sets, pages/views and elements, workflows, and privacy rules. The agent then recreates your app in code based on what it finds, in the language and framework you choose.

For security reasons, the MCP can't read sensitive information like API keys. If you want to reuse them in your new app, copy them over by hand. Treat API keys like passwords, and don't share them with an AI agent.

What the MCP gives your agent	What you set up yourself
Your app's pages, data structure, and workflows	Hosting for your app and its backend
Read access to your app's data	A database, and the migration of your data into it
A map of your app that the agent works from	User accounts, authentication, and access control
	File storage, domains, monitoring, and backups

Rebuilding your app in a new stack doesn't mean you have to take your Bubble app offline. It keeps running while you rebuild, so you can take the time you need and switch over when you're ready.

Before you decide

Moving your app to code is a big project, and for some teams it's the right one. Here are the most common reasons people make the move, and what each one involves in practice:

Reason	What to consider
Your team has developers who want to work in code	Rebuilding in code can be a good fit. Plan for the ongoing maintenance your team will take on.
You need a specific stack or infrastructure, for example for a company standard or a compliance requirement	Rebuilding in code can be a good fit. Check that your target setup covers everything in the next section.
You want to own your app and avoid being locked in	Rebuilding in code may be a good fit. Since you can export your app and your data at any time, you can test an alternative setup alongside your Bubble app before deciding.
You want to expand beyond Bubble's capabilities	Before you move, check whether you can add what you need inside Bubble, with a plugin, the API Connector, or custom code in an HTML element. If the scope of your project goes beyond what those options can cover, rebuilding in code can give you the flexibility you need.
You're comparing the total cost of running your app	Costs in code are spread across multiple providers and services, so it can help to list them all before you compare.

What Bubble handles today, and what replaces it

Bubble takes care of a lot that you don't see while you build. Each section below maps one area of Bubble to its equivalent in code, with tips for setting it up. Many of these pieces come built into good hosting, database, and authentication providers, so you won't need to build them all yourself. Together the sections work as a checklist for your rebuild.

Database and data structure

In Bubble	In your code	Tips
A hosted, managed database	A database such as Postgres	A managed database service can handle much of the setup, updates, and scaling for you
Data types and fields	Tables and columns in a database schema	Ask your agent to generate the schema from your data types. Fields that hold lists of things usually become separate join tables.
Option sets	Enums or lookup tables	Use lookup tables for option sets that have attributes
Built-in fields like unique ID, Created Date, and Modified Date	Columns in your tables	Keep the unique ID as a column, so references between your records still match after the migration
Searches that update automatically when data changes	Queries, plus real-time updates where you need them	Decide which pages need live updates. Most pages work fine with standard queries.
Automatic backups and restore	A backup schedule and restore process	Many managed databases include automatic backups. Test a restore once, so you know it works.

Privacy rules and security

In Bubble	In your code	Tips
Privacy rules applied to every search, API request, and file	Row-level security in the database, or authorization checks in your API	Use your privacy rules as the spec. Translate each one, and cover API endpoints and file downloads as well as pages.
Up-to-date protection against common attacks	Input validation, rate limiting, and protection against injection attacks	Use your framework's built-in protections, and add rate limiting to login and signup
Encryption in transit and at rest	TLS certificates and database encryption	Most hosting and database providers include these by default
DDoS protection	A CDN or edge provider with DDoS protection	Putting your app behind a CDN usually covers this
Security scanning in the Security Dashboard	Security testing and dependency scanning	Turn on automated dependency scanning in your code repository

What is row-level security (RLS)?

Row-level security is a database feature that controls which rows each user can read or change. It's the closest equivalent to Bubble's privacy rules. Each rule is written as a policy on a database table, and the database applies it to every query. A good approach is to ask your agent to write one policy for each privacy rule, and then test them by logging in as different users.

User accounts and authentication

In Bubble	In your code	Tips
Signup, login, and sessions	An authentication provider, or your own implementation	An authentication provider handles sessions, cookies, and logout for you
Secure password storage	Password hashing with a modern algorithm	Authentication providers handle this, so you rarely need to build it yourself
Email confirmation and password reset	Token generation, expiry, and email sending	Most authentication providers include these flows and their email templates
SSO and two-factor authentication (2FA)	The same features in your new setup	Check that your provider supports the login methods your users rely on
Social logins like Google	OAuth apps registered for your new domain	Register a new OAuth app with each provider, using your new domain in the redirect URLs

What is password hashing?

Apps don't store passwords as plain text. They store a hash, a scrambled version that can't be turned back into the password. When a user logs in, the app hashes what they typed and compares the two. Bubble handles this for you, and most authentication providers do too.

Workflows and logic

In Bubble	In your code	Tips
Frontend workflows	Client-side code and calls to your backend	Keep anything that touches sensitive data on the server
Backend workflows and API workflows	Server functions or API endpoints	Require authentication on each endpoint where your Bubble workflow did
Scheduled workflows	A job queue	Many hosting platforms include background jobs. Recreate any jobs that are already scheduled when you switch over.
Recurring events	Scheduled jobs, often called cron jobs	Most hosting platforms support cron jobs. Set the time zone explicitly.
Database trigger events	Database triggers or event handlers	Add conditions so a trigger doesn't set off another trigger in a loop
Custom events and conditions	Functions and conditional logic	Usually straightforward to translate

Some of Bubble's behavior is easy to overlook because it's visualized in the editor: the order actions run in, how dates are stored and shown in different time zones, and how searches update on the page. Writing tests for these early can save you time later.

What is a job queue?

A job queue is a service that stores tasks to run later and runs them when it's time. If a task fails, the queue can retry it. In Bubble, the Schedule API workflow action and the scheduler handle this for you. Many hosting platforms offer a job queue as a built-in service.

File storage

In Bubble	In your code	Tips
File and image storage	Object storage from a cloud provider	Many hosting platforms bundle file storage with their other services
Private files protected by privacy rules	Signed URLs or access checks on every download	Keep private files in a private storage bucket and serve them through signed URLs
Image resizing and delivery through a CDN	An image processing service and a CDN	Many storage and CDN providers can resize images on the fly
File URLs stored in your database	Files moved to your storage, and URLs updated	See Files for how to move them

Integrations and APIs

In Bubble	In your code	Tips
API Connector calls, with keys kept on the server	Server-side API calls and a secure place for keys	Store keys as environment variables or in a secrets manager
Plugins	Libraries or custom code	Many plugins connect to a service that has its own official library you can use
The Data API and Workflow API	Your own API endpoints	Keep the same paths where you can, or update the systems that call them
Payment, email, and other integrations	Direct integrations with each service	Use each service's official library, and register webhooks for your new URLs

Hosting, performance, and reliability

In Bubble	In your code	Tips
Hosting for your pages and backend	One or more hosting providers	A platform that hosts your frontend and backend together keeps the setup simpler
Scaling as your app grows	Autoscaling or capacity planning	Many hosting platforms scale automatically. Check the limits on your plan.
CDN delivery	A CDN	Often included with your hosting
Uptime and failover	Redundancy across servers or regions	Start with what your hosting provider offers, and add more as your app grows
Logs, workload metrics, and alerts	Logging, monitoring, and alerting tools	Set up error tracking and uptime alerts before launch
Platform updates and security patches	Updates to your dependencies, runtime, and servers	Managed hosting and automated dependency updates take care of much of this

Environments, version control, and deployment

In Bubble	In your code	Tips
Development and live versions	Separate environments, each with its own database	Use a separate test database, and keep production data out of it
Branches, version history, and savepoints	Git	Keep your code in a Git repository from day one
Deploying with one click	A deployment pipeline (CI/CD)	Many hosting platforms deploy automatically when you push to your main branch

What is CI/CD?

CI/CD stands for continuous integration and continuous deployment. It's an automated process that tests your code and deploys it to your servers when you push changes. It's the equivalent of Bubble's deploy button, and many hosting platforms include a basic version you can turn on.

Domains and SEO

In Bubble	In your code	Tips
Connecting your custom domain	DNS records pointing to your new hosting	Lower your DNS records' TTL a day before you switch, so the change takes effect faster
HTTPS certificates that renew automatically	Certificate setup and renewal	Most hosting providers issue and renew certificates automatically
Sitemap, robots.txt, and page metadata	Generated or configured in your code	Ask your agent to recreate them from your pages' SEO properties
Page URLs	Your new routes	Keep your URLs the same, or redirect the old ones, to protect your search ranking

What is TTL?

TTL (time to live) is a setting on each DNS record that tells the internet how long to cache it. A lower TTL means a DNS change reaches users faster.

Compliance

Bubble's SOC 2 Type II report and GDPR-compliant data processing agreement (DPA) cover the Bubble platform. When your app runs on your own infrastructure, your hosting providers' compliance and your own processes take their place. Many hosting providers publish SOC 2 reports and offer DPAs, which can be a good starting point if your customers ask for them.

If your app is hosted in a specific region on Bubble, choose hosting in the same region to keep your data residency the same.

Native mobile apps

In Bubble	In your code	Tips
Native builds for iOS and Android	Your own build setup	Set up your own Apple and Google developer accounts early
App store submissions	Submitting builds yourself	Allow time for review with each release to the App Store and Google Play Store
Over-the-air (OTA) updates	An OTA update service, or app store releases only	Plan how you'll reach users who still have the old version installed
Push notifications	A push notification service	Move existing device tokens

Rebuilding your app step by step

Once you've planned what replaces each part of Bubble, you can start rebuilding.

Connect the Bubble MCP. Connect your AI agent to your app using the Bubble MCP. See Bubble MCP for instructions for Claude Code, Codex, and other agents.
Review what your app contains. Ask the agent to list everything in your app: data types, option sets, pages, workflows, privacy rules, API calls, and plugins. Use this as your checklist for the rest of the rebuild.
Set up your new stack. Choose and set up your database, hosting, and authentication before the agent starts building, so it writes code for the setup you'll actually use.
Recreate your app in code. Work through your app in parts instead of all at once. A good order is the data structure first, then authentication and access control, and then pages and workflows.
Rebuild access control. Translate each privacy rule into your new setup. Then test it by logging in as different users and checking that each one only sees what they should.
Migrate your data and files. Move your data and files to your new database and storage. See Moving your users and data for details.
Reconnect your integrations. Set up API keys, webhooks, and OAuth apps for each service your app uses.
Test side by side. Compare your new app with your Bubble app, feature by feature, before any real users see it.

Moving your users and data

Passwords and logins

Bubble doesn't export user passwords. This is standard security practice: passwords are stored in a form that can't be read back (even by the Bubble team), and they don't leave the system that protects them. As a result, users can't log in to your new app with their current password.

There are two ways to handle this:

Option	How it works	Things to consider
Ask users to reset their password	When you switch over, users set a new password the first time they log in to your new app.	Simple to set up. Let your users know ahead of time, so the reset doesn't come as a surprise.
Use your Bubble app as a login provider	Your Bubble app works as an OAuth identity provider for your new app. Users log in with their existing Bubble credentials, and your new app trusts that login.	Users keep their current password during the transition. Your Bubble app needs to keep running for as long as you use it this way.

Using your Bubble app as a login provider can work as a bridge. Your users can keep logging in as usual while you ask them to set a new password, or move them over gradually, and you can turn off the Bubble login once everyone has moved.

Exporting your database

There are three ways to get your data out of Bubble. Which one fits best depends mainly on how much data your app has:

Method	Best for
Reading data through the MCP	Building and testing your migration with a sample of your data
Exporting from the editor	Smaller apps, or moving a few data types by hand
The Data API	Larger apps, or moving all your data with a script

A good approach is to build and test your migration with a sample of your data through the MCP first, then move the full database with an editor export or the Data API when you're ready to switch over.

Exporting from the editor

Open the live database. Go to the Data tab and open the App data section. Click Switch to live database so you're exporting your live data instead of your test data.
Select a data type and set the needed constraints. Select a data type, then set up the view and constraints to show the records you want to export.
Export as CSV or JSON. Click Export, choose your preferred format, and confirm. You'll get an email with a download link when the file is ready. Large datasets can take some time to generate, so download the file as soon as it arrives.
Repeat for each data type. Each data type is exported separately, so repeat these steps for every data type in your app.

Exporting with the Data API

The Data API lets a script read your app's records directly, so you can move all your data in one automated run instead of exporting each data type by hand. You can ask your AI agent to write the script for you.

To use it, enable the Data API in the Settings tab, under the API section, and select the data types you want to expose. The script then reads each data type page by page, and writes the records to your new database.

Requests made with an admin API token bypass your app's privacy rules. Keep the token secret, and consider disabling the Data API again once your migration is done.

Files

Your CSV and JSON exports include a URL for each file and image in your database. To move your files, download each one from its URL, upload it to your new storage, and update the URL in your new database. For more than a handful of files, you can ask your AI agent to write a script that does this for you.

File URLs in Bubble start with // instead of https://. Add https: to the start of each URL before you download it.

Keeping data in sync

While both apps are running, your Bubble app keeps receiving new data. Plan how to handle this: either a final sync just before you switch, or a short period where the app doesn't accept changes. Searching for records by Modified Date can help you find what's changed since your last sync.

Switching over

Do a final data sync. Stop new changes in your Bubble app, or sync the latest data to your new app.
Update external services. Point webhooks, API integrations, and OAuth redirect URLs to your new app.
Switch your domain. Update your DNS records to point to your new hosting. DNS changes can take up to 24 hours to take effect.
Monitor closely. Watch your logs and error reports during the first days, and have a plan for rolling back if needed.
Keep your Bubble app until you're sure. Keep your Bubble app until you've confirmed that everything works and all data and files have been moved.

Once you delete your Bubble app, you won't be able to get its data back.

After you've moved

Once your app is live on its new setup, a few tasks become part of your regular routine. Much of this can be automated, and good hosting and authentication providers take care of parts of it for you.

Area	What it involves	Tips
Security updates	Keeping dependencies, runtimes, and servers up to date	Turn on automated dependency updates and security alerts in your code repository
Monitoring	Knowing when something breaks, and fixing it	Set up error tracking and uptime alerts, and decide who gets notified
Backups	Backing up your data and being able to restore it	Use your database provider's automatic backups, and test a restore now and then
Scaling	Adjusting capacity as your traffic changes	Review your usage regularly, or use a platform that scales automatically
Compliance	Meeting your customers' and your industry's requirements	Keep a list of your providers and their compliance reports, so you can answer customer requests
Costs	Tracking hosting, storage, and third-party services	Set up billing alerts with each provider

FAQ: Rebuilding your app outside Bubble

Does Bubble export ready-to-run code?

No. Bubble doesn't export your app as ready-to-run code. Your AI agent reads your app through the Bubble MCP and recreates it in code. The result is a new codebase that needs to be built, reviewed, and tested like any other software project.

Your Bubble app still gives you a solid starting point. Its design, data structure, pages, and workflows work as a detailed blueprint, so the agent knows what to build and how the app should behave.

Which languages and frameworks can I export to?

You choose. Bubble doesn't export code in a fixed format. Your AI agent reads your app through the Bubble MCP and recreates it in whichever language and framework you ask for.

When you pick a stack, it often helps to choose one your team already knows, and one that covers what your app needs, such as a database, authentication, and file storage.

Do my users have to reset their passwords?

Usually, yes. Bubble doesn't export user passwords. This is standard security practice: passwords are stored in a form that can't be read back, and they don't leave the system that protects them. You can ask your users to reset their password when you switch over, or use your Bubble app as a login provider during the transition. See Passwords and logins for both options.

What happens to my Bubble app when I export?

Nothing changes. Your agent only reads your app to recreate it in code, so your Bubble app keeps running on your current plan until you change or delete it.

Can I move only part of my app?

Yes. Some teams keep their Bubble app and move specific parts to external services that they connect with the API Connector or the Workflow API.

How is this different from the JSON export?

The JSON (.bubble) file in the Settings tab is a record of your app's structure. It can't be run outside Bubble, but an AI agent can also use it as a starting point to understand your app and recreate it in code.

With a JSON export, you may need to give the agent more context to understand your app. In most cases, we recommend using the MCP instead.

Can Bubble support help me move my app?

Our support team can help with the parts of the process that happen in Bubble, such as exporting your data or connecting the Bubble MCP. Once your app is rebuilt outside Bubble, the new codebase, hosting, and AI agent fall outside what our support team can help with. For those, the providers you choose are the best place to turn.

Exporting your Bubble app