> For the complete documentation index, see [llms.txt](https://manual.bubble.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://manual.bubble.io/account-and-marketplace/application-and-data-ownership/exporting-your-bubble-app.md).
# Exporting your Bubble app
Bubble allows you to export your app. Using the [Bubble MCP](/help-guides/ai/bubble-mcp.md) (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.
{% hint style="info" %}
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.
{% endhint %}
| 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 |
{% hint style="info" %}
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.
{% endhint %}
## 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.
{% stepper %}
{% step %}
#### 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.
{% endstep %}
{% step %}
#### 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.
{% endstep %}
{% step %}
#### 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.
{% endstep %}
{% step %}
#### 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.
{% endstep %}
{% step %}
#### 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.
{% endstep %}
{% step %}
#### Migrate your data and files
Move your data and files to your new database and storage. See Moving your users and data for details.
{% endstep %}
{% step %}
#### Reconnect your integrations
Set up API keys, webhooks, and OAuth apps for each service your app uses.
{% endstep %}
{% step %}
#### Test side by side
Compare your new app with your Bubble app, feature by feature, before any real users see it.
{% endstep %}
{% endstepper %}
## Moving your users and data
### Passwords and logins
{% hint style="warning" %}
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.
{% endhint %}
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](/help-guides/ai/bubble-mcp.md) | Building and testing your migration with a sample of your data |
| [Exporting](/help-guides/data/the-database/export-import-data/exporting-data.md) from the editor | Smaller apps, or moving a few data types by hand |
| The [Data API](/help-guides/integrations/api/the-bubble-api/the-data-api.md) | Larger apps, or moving all your data with a script |
{% hint style="info" %}
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.
{% endhint %}
#### Exporting from the editor
{% stepper %}
{% step %}
#### 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.
{% endstep %}
{% step %}
#### 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.
{% endstep %}
{% step %}
#### 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.
{% endstep %}
{% step %}
#### Repeat for each data type
Each data type is exported separately, so repeat these steps for every data type in your app.
{% endstep %}
{% endstepper %}
#### Exporting with the Data API
The [Data API](/help-guides/integrations/api/the-bubble-api/the-data-api.md) 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.
{% hint style="warning" %}
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.
{% endhint %}
### 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.
{% hint style="info" %}
File URLs in Bubble start with `//` instead of `https://`. Add `https:` to the start of each URL before you download it.
{% endhint %}
### 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
{% stepper %}
{% step %}
#### Do a final data sync
Stop new changes in your Bubble app, or sync the latest data to your new app.
{% endstep %}
{% step %}
#### Update external services
Point webhooks, API integrations, and OAuth redirect URLs to your new app.
{% endstep %}
{% step %}
#### Switch your domain
Update your DNS records to point to your new hosting. DNS changes can take up to 24 hours to take effect.
{% endstep %}
{% step %}
#### Monitor closely
Watch your logs and error reports during the first days, and have a plan for rolling back if needed.
{% endstep %}
{% step %}
#### 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.
{% endstep %}
{% endstepper %}
{% hint style="warning" %}
Once you delete your Bubble app, you won't be able to get its data back.
{% endhint %}
## 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.