Can You Export Your Bubble App’s Code? What Is Actually Inside a .bubble File

If you’re looking for an Export Source Code button in Bubble, you won’t find one.

Bubble lets you export your application as a JSON file and export your database data separately. What it doesn’t give you is a conventional source-code repository that you can deploy to your own infrastructure or hand to a developer as a working codebase. Bubble’s own documentation is explicit about this: Bubble apps run on the Bubble platform and can’t be exported as code.

That’s the short answer.

The longer answer is more useful, especially if you’re asking because of a funding round, acquisition, enterprise deal, or possible move away from Bubble.

The application export isn’t source code, but it isn’t useless either. It can tell you a lot about how your product is built, and it can be extremely valuable when you’re planning a rebuild.

Here’s what you actually get, what you don’t, and what that means if you eventually want to leave Bubble.

If you’re looking at this from a technical due-diligence perspective, our resources for CTOs and engineers cover the migration side in more detail.

Can you export source code from Bubble?

No. You can export a Bubble application definition and your application data, but you can’t download the app as runnable source code and host it somewhere else.

It’s worth separating three questions that often get bundled together:

Bubble’s documentation confirms that applications can be exported as JSON. It also says that Bubble apps rely on Bubble’s engine and can’t simply be exported and run somewhere else.

This isn’t a recent change, either. Founders have been asking about it for years. In a Bubble Forum thread from January 2016, Bubble co-founder Emmanuel Straschnov explained that moving away from the platform requires rebuilding the application’s logic.

That’s still the important distinction today.

What does Bubble’s application export actually contain?

Bubble’s application export is a structured description of your app. It’s useful for understanding what you’ve built, but it isn’t an implementation that can run on its own.

A simple way to think about it is this:

The export is a blueprint, not the building.

It can give you visibility into the structure of the application: pages, elements, data definitions, workflows, states, styles, and other configuration used to describe how the product works.

That’s valuable during a migration because you don’t have to reconstruct the entire product from screenshots and conversations with the original developer.

You can inspect what’s actually there.

What is a .bubble file?

When people talk about a .bubble file, they’re generally referring to the structured application definition behind a Bubble app. Bubble’s current documentation describes application export as JSON.

That distinction matters because this isn’t a folder containing React components, API routes, database migrations, and configuration files.

It’s a representation of the application that Bubble understands.

For migration work, that representation can help identify things such as:

• pages and their structure;
• data types and fields;
• workflows;
• custom states;
• styles;
• responsive behavior;
• dependencies that need to be investigated before rebuilding.

We use this information when we’re trying to understand the real scope of an existing product.

It’s also possible to recover useful parts of the visual system rather than recreating everything by eye. We explain that process in more detail in extracting a design system from a Bubble export.

The important point is that the export describes your Bubble app.

It doesn’t turn it into Next.js, React, Node.js, Python, or any other independently deployable application.

Can you export your Bubble database?

Yes. Bubble provides built-in tools for exporting application data, and its current documentation lists CSV, JSON, and Newline-Delimited JSON (NDJSON) as available export formats.

From Data → App data, you can select the data type and records you want to export and choose the appropriate format.

For larger migrations, Bubble also recommends API-based access as a more scalable option in some cases.

Getting the records out, however, is only part of moving a production database.

Imagine your data looks something like this:

Users → Companies → Projects → Invoices

You don’t just need four sets of records. You need those records to maintain the same relationships after they move.

Files need to be accounted for. References between custom data types need to be mapped. Option sets need somewhere to go. IDs and metadata need to be handled deliberately rather than copied blindly.

Bubble’s own import documentation illustrates some of these differences. References to custom data types, for example, can rely on Bubble unique IDs, while fields such as Creator, Created Date, Modified Date, and Unique ID are managed by Bubble itself.

So yes, you can get your data out.

Moving it cleanly into a different database is the part that requires planning.

What doesn’t the Bubble export include?

It doesn’t include the Bubble platform itself.

That’s the piece that makes the application run.

You don’t get Bubble’s runtime as part of your app export. You don’t get its server-side workflow engine as code you can deploy yourself. And a third-party Bubble plugin doesn’t become portable application code simply because your app uses it.

This is why you can’t take an exported Bubble application, upload it to AWS or Vercel, and start it.

Bubble explains this architecture in its own documentation: although Bubble can be described as generating code behind the scenes, the application depends on Bubble’s server engine, with the client and server sides working together as part of the platform.

If you move away from Bubble, those behaviors have to be implemented in the new application.

That’s what people sometimes miss when they hear the word export.

Why aren’t “I can export it” and “I own the code” the same thing?

Because owning your product and having a portable source-code repository are two different things.

Bubble says you own your app’s design and your data, while Bubble retains ownership of the underlying code that powers the platform. The same documentation states that Bubble applications can’t be exported as code and run independently.

There’s no contradiction there.

It’s simply how a hosted development platform works.

You get the speed and convenience of building on Bubble’s infrastructure. In return, the application depends on that infrastructure.

Three questions make the distinction easier to see.

The portability test

Could you give the export to a developer and have them deploy the same application to another hosting provider?

No.

They could use the export as a reference for a rebuild, but the export itself isn’t a deployable application.

The hiring test

Could you hand the exported app to a general React, Next.js, Node.js, or Python developer and have them continue working on the same codebase?

No.

They would be rebuilding the product in a different stack.

The continuity test

If you decided to leave Bubble tomorrow, could you take the latest export and keep the same application running somewhere else?

No.

Bubble states that moving off the platform requires rebuilding the application logic.

None of that makes Bubble a bad platform.

It’s a tradeoff.

Bubble takes care of a lot of the engineering and infrastructure that a conventional application team would otherwise have to build and maintain. That’s a big part of why founders can get sophisticated products to market without hiring a full engineering team.

The tradeoff is portability.

Has this always been the case?

Yes. Questions about exporting Bubble applications have been around almost as long as the platform itself.

A Bubble Forum thread from January 2016 asked directly about migrating code and data out of Bubble. Bubble’s co-founder responded that Bubble applications run on the Bubble platform and that moving away would require rebuilding the application logic.

The thread is useful because the concern sounds remarkably familiar even years later: founders want to know what happens if they build a significant business on a hosted platform and eventually need to leave.

That’s a reasonable question.

But it’s better framed as a portability decision than as a debate about whether Bubble “locks you in.”

Every architecture creates dependencies. The useful question is whether those dependencies still make sense for your business.

What is the Bubble export actually good for?

Quite a lot.

The fact that you can’t run the export independently doesn’t make it useless. If you’re considering a rebuild, it’s one of the first things worth looking at.

Documenting an app nobody has fully documented

Production apps tend to accumulate history.

• Someone added a workflow two years ago.
• Another developer changed it six months later.
• A plugin was introduced for one feature.
• The database grew.
• New roles and permissions appeared.

Eventually, different people understand different pieces of the product, but nobody has a complete view.

The application export gives you a much better starting point for an audit.

Instead of asking, “How many workflows do we think there are?” you can inspect the application itself.

That alone can uncover complexity the team has forgotten about.

Scoping a rebuild

Counting screens is a poor way to estimate a migration.

Two apps can each have 20 pages and be completely different projects.

One might be a fairly simple CRUD product. The other might have hundreds of workflows, payments, multiple user roles, scheduled processes, external APIs, plugins, and years of edge cases.

Those are very different rebuilds.

The application definition helps expose the complexity before anyone starts making promises about timeline or price.

That’s what our free migration estimator is designed to do: look at the application you actually have rather than guess from a demo or a set of screenshots.

Recovering your design system

A migration doesn’t have to be a redesign.

In fact, changing the interface at the same time as the underlying architecture can add risk for no good reason.

The existing application contains useful information about its visual system. Styles, typography, spacing, responsive behavior, and other design decisions can be identified and carried into the new build instead of being recreated by eye.

We’ve covered the technical side of that in how we extract design systems from Bubble exports.

The goal isn’t to build something that looks approximately like the old app.

It’s to preserve what already works while replacing what needs to change underneath it.

What does real code ownership look like?

In a conventional custom-code setup, the codebase sits in a repository your company controls. Your organization has access to the repository and hosting accounts, and another qualified engineer can take over the application without rebuilding it first.

That doesn’t make custom code automatically better.

It also means someone has to maintain that code, manage dependencies, handle infrastructure and security, and keep the application healthy after the migration.

Ownership comes with responsibility.

At Bubble to Code, the point of moving to code isn’t to replace dependency on Bubble with dependency on us. The codebase and repository are yours. You can see what our code handover includes or compare Bubble vs. custom code before deciding whether that tradeoff makes sense.

How do you export a Bubble app?

Bubble lets you export the application itself from the editor’s Settings area. The application export is separate from your database export.

The exact interface can change, but the process is straightforward:

1. Open your app in the Bubble editor.
2. Go to Settings.
3. Find the application import/export controls.
4. Choose Export application.
5. Save the exported JSON file somewhere secure.

Don’t treat this as an ordinary document.

Your application export can reveal a lot about how the product works. If you’re sending it to an outside developer or migration company, make sure you know how the file will be stored and who will have access to it.

You can review our security and NDA policy before sending an application to Bubble to Code.

How do you export data from Bubble?

Database data is exported separately from the application definition.

Bubble’s current process is:

1. Go to Data → App data.
2. Select the data type you want to export.
3. Set the view to include the records you need.
4. Click Export.
5. Choose your export format.
6. Download the file once the export is ready.

Bubble currently supports CSV, JSON, and NDJSON for database exports.

For a small application, manual exports may be enough.

For a large production database, the migration may be better handled programmatically rather than by manually moving files. Bubble itself recommends API-based access for larger volumes in some circumstances.

Either way, keep a clean copy of the original export before you start transforming anything.

Should you migrate just because Bubble doesn’t export source code?

No.

If Bubble is doing what you need, your costs make sense, your customers are happy, and you don’t have a concrete reason to own an independent codebase, the lack of source-code export isn’t a reason by itself to rebuild the product.

Ask a more useful question:

What would owning the code actually change for the business?

• Maybe you’re preparing for an acquisition and technical portability has become part of due diligence.
• Maybe an enterprise customer has infrastructure requirements you can’t meet today.
• Maybe performance or workload costs are becoming difficult to manage.
• Maybe the product now needs functionality that doesn’t fit comfortably into the existing architecture.

Those are reasons to investigate.

“We should probably own the code now” isn’t much of a business case on its own. If you’re weighing the bigger decision, see nine signs it’s time to move off Bubble.