For the past 20 months, I’ve given assistance on an app that required the intensive use of sub apps and since the documentation so far has been vague and I saw quite a lot of questions around it, I thought I share my experiences here.
Why did we initially go for the sub apps?
The main reasons why we needed these sub apps:
We needed separate URLs for each client
We needed a separate database for each client
Styling needed to be done differently for each client
We needed separate email addresses that send out the emails for different clients.
At the time, we needed an upgrade towards a higher plan for the first client (now main app). So this lowered the threshold a bit in switching towards a ‘production plan’ for this main app.
Would I recommend it? Not necessarily. There might be different ways in achieving some of these goals and it does give some extra head aches to align all environments.
Especially (2), (3) and (4) could have been dealt with differently:
I’ve seen some options out there to set up different domains pointing to the same Bubble app, but for me they triggered more questions than they answered. A lot of them made use of redirects that caused a series of other problems (for example the use of parameters in the URL, sometimes a loss of speed in loading the right page, impacts on SEO, etc). If anyone has other experiences with this, feel free to share them in the comments!
You should ask yourself: why do you even need a separate database? Consistent use of a ‘configuration’ parameter can achieve the same results.
Even when using sub apps, you will need to arrange your difference in styles and color codes entirely through the database. Same goes for setting favicons, OG tags and description. There’s little to no need for a main-sub apps setup for this.
This can be achieved by simply setting up your own email API with postmark, sendgrid or another service. The only downside might be that you ‘lose’ some of the standardized email features in Bubble, but it’s not worth moving to a sub apps construction for this.
Although it was necessary to move to a higher plan for this one application, it also meant having all other apps on completely seperate plans. There is no pooling of capacity and you risk paying more than you would otherwise. For this project this wasn’t necessarily an issue as individual clients would also have to pay for their ‘usage’, but still.
Other things you need to know
Along the way, we learned a few things we hoped to have know from the start. Most importantly:
You can’t push to only one sub apps. It’s all or nothing at the same time.
When you push your main app’s version to “all sub apps”, it doesn’t just overwrite the version in your development environment. It also overwrites the live environment of all sub apps towards the version that happens to be live in your main app. This is especially painfull when you have the need to roll out a release per sub app separately (think off post-release actions you need to take, settings you might want to change in your client’s environment before releasing)
There is no logging on this ‘overwriting’ of software versions/releases that are done through the ‘push to all sub apps’ action. So if a bug appears: go fetch! Your logs might say you recently released to the latest version, but your app might have rolled back to ancient version ninja-style.
All admins can access the ‘push to all apps’ button. Working in teams can be messy in Bubble. While I trust all devs I work with, not everyone who has access to this button might be fully aware of it’s impact on all of your live environments.
Last, but not least: I don’t think this is a high priority for Bubble. As is the case with most features and tools for professional bubble users and agencies, it is not necessarily the focus of the team at this point. Taking into account that (as far as I can tell on the forum) almost nobody seems to be using sub apps, it’s doubtful the flaws in this sub-apps system will get a lot of attention or change is to be expected.
Anyway, those are my 2 cents. Feel free to add anything I might have missed! I’m curious to hear your thoughts!
Thanks for sharing. I wish Bubble could at least do a video explaining the sub-app feature as I’m sure it would help them sell more plans if more people could understand its use cases better.
Given the pretty significant price jump for sub-apps, especially from the lowest-paid plan. If all someone wants to achieve is a unique URL for each customer, is it not just better to duplicate the app with a different name?
Haven’t looked into this yet and I’m now just realising I may have to fork out a bunch of cash.
You’ll be facing quite some head ache if you need to sync the different environment’s versions. Depending on how you would see this in action, it might be an option to just copy paste apps, but keep in mind that:
there will be a clean cut between the ‘original’ and ‘copied’ apps
there is no clean way to deploy 1 version throughout all the apps (You might be able to roll out new versions for the copied apps by importing the entire redacted version, but that sounds tedious and not really what it is meant for).
(as mentioned in my original post) if all you need is a unique URL, you might want to explore services like coalias. We’ve implemented coalias for another client and it seems to do the job well (allthoughit does come with a cost).
Every Sub-App will be using their own processing power, the only benefit I see for having Sub-Apps is to deploy new functionalities or optimizations, but then again, you could simply use the “Copy to another app” functionality, mainly if there is some personalization within the sub-apps.
I don’t understand why can’t bubble apply the same “Merge” logic within branches so you can choose what to update on sub-apps.
Thanks for the insight.
Clearly, the Bubble doc is much too light on this topic.
One thing that isn’t very clear to me : are Option Sets pushed to sub-apps or can sub-apps have their own OS ?
Option sets are managed in the main app. Once pushed to the subapps, any changes on the Option Sets in the subapps are overwritten by the Master/Main app.
Thanks @Build-More
That seems really weird…
So how do you set the parameters for your different sub-apps ?
Let’s say each sub-app has a different logo / main color. How is this kept in each sub-app without having to reset everything every time you push new features ??
@Build-More thank you for this insight. It is very helpful as I am debating setting up a new app with sub-apps or just make duplicate apps (which sounds like a nightmare if they need to be constantly updated)
Question… Can each sub-app have its own domain? I know they can use sub-domains, but I want each client on their app to be able to have www.client1.com and www.client2.com. This does not seem possible?
Typically, when working with sub apps, you would keep everything that is specific for the sub-apps (and not generic for all) in a configuration record (a seperate datatype you would create). The downside of this is that you will need a bit more searches for every page load of logged out users + Some additional data to your user record.
There might be other ways to deal with this. For a while, I was toying around with the idea to keep a seperate ‘URL’ parameter all Option Sets that needed differentiation accross sub apps, when referring to these Option Sets, you would include a filter based on the current URL basepath. But I doubt that this is a faster/better way to tackle things…
And this is where things become a bit confusing and less well documented; the settings tab for sub apps is a mess. Some parts are not overwritten when you do a ‘push to all sub apps’ (for example the domain set up) while others are (SEO settings, including the site title and header) .
OK thanks everyone for the insight. I’m seriously looking into sub-apps for a project but at this time it doesn’t seem like the potential is fully there yet… And it doesn’t seem to be a priority for Bubble right now compared to AI / mobile… It’s a shame because it could really be powerful…
Well, the idea is to have dedicated versions of my main SaaS app that don’t have all the conversion mechanisms, have entierly separated databases (maybe event have those dbs on Xano in France). Each needs to have it’s own url, SSO, API connexions to company tools and some simple visual styling…
I’m affraid you’ll run into a few obstacles for the SSO. Either you need to get all SSO’s working for both your main app and every sub app (which is probably not a desirable outcome), or you need to cut the ties for updates with your main app (in which case, you don’t really need a sub app setup, but rather a copy that you can then modify).
Unless you found a way around using the Bubble API connector to setup the SSO, I don’t really see this working with a sub apps setup
compared to AI / mobile… It’s a shame because it could really be powerful…