Multiple apps att same domain?

Just started today with Bubble. I’ve successfully uploaded my first app to the domain I purchased today.

Question: is there a way to deploy my apps to sub-folders at my domain so that I can have multiple apps at the same domain? For instance, “adomain dot com/onapp” and “adomain dot com/anotherapp”.

Possible?

I don’t know whether it’s possible to include them as a folder, but you can definitely do it as a subdomain.

1 Like

Thank you! I see it.

Do you suppose that I’d then just deploy from Bubble to the sub? For instance, if I’m not deploying to

adomain dot com, I would simply deploy to subdomain.adomain dot com, right from Bubble?

Thanks.

You’d probably have a separate app for each subdomain. So, you’d deploy each separately. Of course, you’d be able to get them to talk to one another through the API if you wanted.

Unless, of course, you’re trying to run a different instance of a single app (e.g., one for each customer) or something like that. Then, you’d have a single app and push changes to each sub-app.

Bubble gives you a lot of options. I’d search through the forums if you’re trying to understand it better since there’s been a lot of discussion of these topics in the past.

2 Likes

The concept you’re exploring is single tenant (one company) versus multi tenant (many companies). (Simplifying things a bit, but for the sake of introduction).

Bubble’s subdomains (ex tentant.yourdomain.com) is the single tenant approach when you’re using a common core structure for an application. Conversely, yourdomain.com/tenant is an example of multi-tenant.

In an multi-tenant solution, everyone is sharing the same database. Your data is restricted in access from other users based on privacy conditions and display rules.

In a single tenant solution, only one company exists within that instance. (acme.yourdomain.com’s data is in a different database than disney.yourdomain.com).

If your solution is like a social network, that’s where you go multi-tenant. (What Linkedin does is they have a “page” for profiles, where content is rendered. Ie., when you go to linkedin.com/in/johnsmith, it’s inserting John Smith’s profile details in the “in” profile page. (No actual pages are created for the users, it’s just inserting data into a template).

5 Likes

Excellent! That is exactly what I want to hear: options. I have not decided yet which way I will go. But, it’s great to know that either is available. I had been dismayed thinking I’d have to buy a new domain for every customer.

Of course. For a bit more context…

When you use sub apps on Bubble, effectively your creating clones of your app. (Each functions independently but make take direction from the parent application. Much like a teenager going off to college :smiley: )

So, with subdomains, it can “re-use” a domain. It’s just adding a modifier to it. (Think of it like apartments in a building. You have the building itself, which is your domain. Then, the individual apartments are the subdomains). So, acme.yourdomain.com is just a more specific place, which Bubble reconciles and points directly to that specific sub app.

1 Like

Does each sub app get a different IP address?

Hi Scott,
Does setting up a different app on a different subdomain require paying for that separate app (I’m thinking the answer is yes??)? So if I wanted to let users access my site through three different subdomains then I’d I’d have to pay for 4 apps (the one apex domain site + the 3 subdomain sites)?

In that case aren’t these 4 apps actually called “parent apps” and not “sub-apps”?

I’m not sure of the pricing model for that structure because it’s not something I’ve done.

@zelus_pudding - there are two ends you can approach this from. (For this example, let’s say you have a SaaS business application).

Scenario one: you want to have your customers have wholly independent applications (different databases, server allocation, etc). This means you have apple.yourapp.com, microsoft.yourapp.com, etc). In this case, you are paying for a) a team plan for the master application (ie. the parent application) and b) a separate bill for each sub application.

Scenario two: you want your customers to “share” a database, but to have their own access. Everyone accesses the app at yourapp.com. However, they should be able to type in apple.yourapp.com and end up at yourapp.com. In this case, you would set up forwarding with your domain name registrar (where apple.yourapp.com would forward to yourapp.com. Once they do so, the “app.” is no longer present). In this case, you are only paying for one application.

If you want subdomains to be persistent (ie. always there), that requires scenario one. (To my knowledge, there is no way within Bubble currently to have multiple subdomains directly associated with a single app).

Let me know if that clears things up. Can be a bit tricky at first.

4 Likes