How to Use Sub-Apps in Bubble? - The Complete Step-by-Step Guide

What is a sub-app in bubble.io?

A sub-app is a separate app instance created from your main Bubble app. It:

• It has its own database (you can optionally copy data from the main app at creation).

• Has its own domain, users, privacy rules, and media uploads.

Shares the editor design, workflows, and data types pushed from the main app.

---

What is the need for sub-apps in bubble.io?

Bubble.io sub-apps are not just copies of your app - they're a strong way to grow your product setup, provide custom deployments, and handle the needs of multi-client SaaS. Whether you're aiming for small businesses or large companies, sub-apps offer flexibility, security, and ease - all within Bubble’s no-code platform.

1. White-label SaaS: Give Each Client Their Own Branded App

One of the most common reasons to use sub-apps is to power white-labeled software.

🔧 Here is the problem sub-apps will solve:

If you offer your product to multiple businesses (e.g., gyms, schools, agencies), each might want its own logo, branding, domain, and client-specific features. Managing all of this in a single app instance can become chaotic and limit scalability.

✅ Solution with Sub-Apps:

• Create a sub-app for each client from the main Bubble app.

• Customize branding, themes, and domain per sub-app.

• Keep the core logic consistent across all clients by pushing updates from the main app.

Each client has a completely isolated database, increasing security and privacy.

2. Enterprise Deployments: One App Per Company

Larger enterprise clients often require full data separation, enhanced security, or compliance with internal policies (like SOC 2).

🔧 Here is the problem sub-apps will solve:

Enterprises may not want to share infrastructure with other users or want full control over data retention and access.

✅ Solution with Sub-Apps:

• Give each enterprise its own sub-app—technically a standalone Bubble app.

• Data is not shared across apps; only the data structure and editor updates are pushed.

• Enterprises can have their own deployment schedules, access policies, and even admin roles.

🛡️ This gives your product a multi-instance architecture without the engineering complexity you'd typically face building it from scratch.

3. Regional Versions: Comply with Local Laws and Optimize Performance

If your app operates across multiple countries or regions, you may need to comply with data localization laws or reduce latency by deploying closer to your users.

🔧 Here is the problem sub-apps will solve:

Running a single app globally might violate data policies like GDPR or create latency for users far from your app’s server location.

✅ Solution with Sub-Apps:

• Spin up sub-apps hosted on different domains or subdomains (e.g., app.company-eu.com, app.company-us.com).

• Keep data physically and logically separated by region.

• Customize privacy rules, legal content, or features based on locale.

🌍 Examples:

• A FinTech app with separate EU and US sub-apps for GDPR and CCPA compliance.

A learning platform with region-specific languages, currencies, and legal disclaimers.

---

How do you create a sub-app from the main app?

You need to upgrade your main bubble app on the Team Plan to have the ability to create a sub-app.

Once you are in Team Plan, you can create a sub-app from any branch by going to Settings → Sub apps → create a sub-app with the app name and DB Copy shown in the image below:

This newly created sub-app will be shown in your bubble.io account with the free plan.

• Important Notes:

  • All Team plan collaborators of the main app won’t be added to the sub-app collaborator.You need to upgrade your sub-app plan to the Growth plan to add more collaborators.

  • No matter which branch of the main app, you are creating a sub-app; the Sub-app will be a replica of the main branch version of the main app.

  • If you ‘remove’ a sub-app from the main app, it won’t be deleting an app. It will just break the connection between the main and sub-app. To delete the sub-app, you need to go to the app and delete it like you delete the regular bubble.io app.

• To save excessive cost, here is what I recommend

  - Give ownership of sub-apps related development to the single developer from your team- Create all sub-apps from that developer's bubble.io account

  - Upgrade that bubble.io sub-app to the starter plan. So the person who needs to work on sub-apps will be working on that with the starter plan.

  - If you need multiple developers working on a single sub-app, then there is no other choice but to upgrade to the Growth Plan to add multiple developers as collaborators in the sub-app. - Make sure you create your business model accordingly.

---

How to Push Updates to Sub-Apps from the main apps?

Here’s a step-by-step guide to safely push updates to sub-apps:

Step 1: Create a Dedicated Branch for Sub-App Changes (Recommended)

Before making changes intended for sub-apps:

• Go to the Branches tab in the Bubble editor.

• Create a new branch (for example: subapp-update-branch).

• Build and test your changes in this isolated branch.

This allows you to separate sub-app-specific changes from other development work.

Step 2: Merge That Branch into the main Branch

Once your updates are tested and ready:

• Merge your working branch into the main branch.

Only the main branch can push updates to sub-apps. No other branch has this ability.

Step 3: Push Changes from the Main App to Sub-Apps

Navigate to:

• Settings → Sub-Apps tab

• Locate the list of connected sub-apps

• Click “Push changes” for each sub-app you wish to update

This process will transfer:

• All editor changes (pages, workflows, logic)

• Data type structures (not data)

Step 4: Revert or Reset the Main Branch (Optional)

If your changes were only meant for sub-apps and not for your live app:

• Revert the main branch to its previous state, or

• Reset the main branch to the live version

This ensures the main The branch stays clean and doesn't accidentally deploy sub-app-specific changes to your production environment.

---

What will be copied from the main app to the sub-app, and what will remain independent in the sub-app?

What doesn’t Get Pushed from the Main app to the sub-app?

The following are not transferred to sub-apps during a push:

• Database records (live data)

• Media files (each sub-app manages its own)

• App settings, domain, and logs

• Plugin-specific configurations unique to each sub-app

---

Special request to bubble.io for specific sub-apps setup

You can request for specific settings to not propogate from main app to sub-app to Bubble team as per Bubble.io manual

Here is the screenshot of specific section:

---

The most important part to implement in existing sub-apps before pushing changes from the main app to sub-apps:

• Create a save point in existing sub-apps before the push.

• When you push to all sub-apps, it won’t raise any conflict with existing sub-app changes that you made separately, and will make all Editor (UI & workflows) and Data Types (structure) the same as the main-app, which you didn’t want for all sub-apps; you will be able to restore your created save point and figure out another way to implement some of the necessary changes from the main-app, but it will save your independent changes made in sub-apps.

---

Best Practices and Tips for Working with Sub-Apps in Bubble.io

Using sub-apps effectively requires not just knowing how to push updates, but also following a disciplined approach to avoid confusion, data issues, or deployment errors.

1. Use Clear Naming Conventions for Sub-Apps

As your number of your sub-apps grows, it’s easy to lose track of which sub-app is for which client, region, or use case.

Recommendation:

• Include the purpose or client name in the sub-app name, such as client-xyz-app, staging-eu, or demo-app-v2.

• Maintain a naming convention that clearly distinguishes between production, staging, and testing environments.

Why it matters:
It improves collaboration, simplifies documentation, and reduces the risk of pushing updates to the wrong sub-app.

2. Keep the Main App Clean — Use Branches for Development

The main app should only reflect the version you want all sub-apps to inherit. Avoid building or testing new features directly in the main branch.

Recommendation:

• Create dedicated branches for feature development or sub-app-specific changes.

• Merge only the final, stable version into main when you are ready to push to sub-apps.

Why it matters:
This minimizes the risk of deploying unstable code across all sub-apps and keeps your main app production-ready at all times.

3. Always Document What Was Pushed and Why

When you push changes to a sub-app, there’s no automated log that tracks what was updated or why. This can lead to confusion, especially in teams.

Recommendation:

• Maintain a change log (in Linear, Notion, Google Docs, Git-style README, etc.).

• Include: what was changed, which sub-app(s) were affected, and who made the push.

Why it matters:
It helps with debugging, accountability, team communication, and audit trails.

4. Backup Your Main App Before Major Pushes

Pushing updates to sub-apps is irreversible—you can’t “undo” a push once it’s done. If something breaks, recovery becomes harder.

Recommendation:

• Before pushing major changes to sub-apps, make a manual backup of your main app by duplicating it or exporting the app JSON.

• You can also use Bubble’s built-in version control to create save points.

Why it matters:
Having a backup gives you peace of mind and a fallback option in case something goes wrong during deployment.

---

Sub-apps in Bubble.io give you a clean, scalable way to serve different clients, regions, or testing environments - all while keeping your core logic centralized.

In this guide, we covered not just how to set up and push updates to sub-apps, but also best practices to avoid breaking your main app.

Whether you're building a white-label SaaS, serving enterprise clients, or working across global markets, sub-apps can save you time, reduce complexity, and improve data isolation.

Use branches, document your pushes, and back up before major changes, and you’ll be well on your way to building a stable, scalable no-code infrastructure.

Got questions? Ask in the comments. To support me, buy me a coffee.