I’ve been meaning to figure this out forever but finally did it tonight, took about an hour and a half.
app.com/anything goes to Bubble, normal. app.com/definedRouteToIntercept goes to whatever I want to make it go to (Ghost, Wordpress, Webflow, whatever), in my case it goes to my docs site.
It’s powered by Cloudflare Workers which acts as an edge router. I think there is a service that does custom domains for Bubble apps and I assume it’s something like this. Note: this is not forwarding the domain and masking, it’s actually pushing the request upstream as needed. About 10 minutes of setup time with knowledge of how to do it.
Bonus: I can now use Cloudflare to control Bubble as all requests hit MY cloudflare account first so I can configure url rewrites, custom routes, cacheing, whatever I want on Cloudflare now.
If anyone’s interested, I can make a tutorial on this!
It’s not really, your request hits Cloudflare before Bubble, which decides whether to route it to Bubble or the other ‘site’ you want to point it to for that path.
I’ve posted the tutorial, it was hastily made so please let me know if anything is unclear. I’d appreciate a like and sub if you found it helpful! I also make cool plugins!
I forgot to mention but this setup also allows more features as Cloudflare gets the request first. Now, you have more options for cacheing, injecting scripts/logic, rewrites, image optimization, tag management and more.
Also, you can have multiple subdomains on a Bubble app through this, and actually control any route on your domain programmatically control a worker via API or the CF API. So a new business user could mean, new route for /business/businessName can be setup at businessSubdomain.app.com.
*That’s not to bash on the existing subdomain solutions that are sold for Bubble, that obv. is managed, but this is def. cheaper and easier once you get a hang of it.
@sudsy mentioned in the tutorial, because that plugin is killer !!
Not at all! It’s just proxying requests to your OWN Cloudflare account before going to Bubble. This way, on edge, you can intercept a request and do whatever you need.
Domain routing only involves DNS records. So all you need to do is point domain paths to whichever destination you want.
It’s the same as when you add the three Bubble IP addresses when setting up your Bubble apps domain. The domain manager is just pointing a domain address to Bubble IPs which are also managed by Cloudflare.
With this method what happens when a domain path is the same as a Bubble page, users will be redirected to the address set in your DNS records.
I haven’t watched the video but I think he’s using Cloudflare workers to do the user routing. So what’s happening is in his DNS records the root is reverse proxied to a Cloudflare Worker which does the routing.
Which would be easier then forwarding using DNS because the worker would route users by matching paths.
Worker extracts the path value and usually a regex match is used to find where to route the user
There’s usually a catch all (paths don’t match any set route) to send the user to the Bubble app, passing the full URL to the Bubble app to do whatever it needs to do with the URL.
You can get the worker to read a KV table (so you won’t need to rewrite the worker code to manage paths) to easily match paths to a URL or even another Worker, DO, Queue etc
Cloudflare is a very powerful reverse proxy service.
Regarding Emails
Emails sent to a domain use MX Records in your DNS to ensure they get delivered to the correct email service.
By default outgoing emails sent from Bubble apps use Sendgrid because the send email actions are programmed to deliver emails using Bubble’s Sendgrid account. Which is why Bubble encourages you to setup your own Sendgrid account.
This is a necessary requirement as there are strict rules for outgoing emails and spamming emails will affect Bubble’s email domain reputation, leading them to be marked as Spam.
See what I mean? Understand and let people know about the limitations of an approach before recommending it.
Yeah, my understand was there was an issue with ipv6 when doing this. There is a setting in Cloudflare that converts ipv6 to ipv4 and supposedly everything works OK if you enable that.
I also found this from another forum thread:
Your logged in Users will have issues - Anyone with a current active cookie will be stuck in limbo. They have a cookie connected to the original servers and you are now on new DNS servers. This creates the famous “can’t log out” loop. We tried to write some scripts to clear the cache or to logout all users, but basically failed and ended up apologizing and telling people how to delete their mysite.com cookies. (If any Forum users know how to do this better, we’d love to know).
I don’t know what other limitations there are or edge cases could happen but I suspect it’s not as easy as “just do it and everything instantly works fine.”
Bubble requires that all connections from a domain are not reverse proxied because Bubble servers are already reverse proxied. So in Cloudflare that means disabling the orange cloud (reverse proxy function).
You can still have your own reverse proxy with a Cloudflare managed domain but best practice is to point your Bubble app to a subdomain or different domain. Subdomains will look nicer since it’s usually something like yourapp.domain.com.
Then you’ll enable reverse proxy for the root domain and get a worker to handle the routing. You’ll want to mask your Bubble app sub domain or else what’s the point if someone can just bypass your reverse proxy by going straight to the subdomain?
It does have some other caveats. Here are some things to consider if you do decide to reverse proxy your Bubble app that I got from ChatGPT:
Practical decision rule
I’d greenlight it if all of these are true:
• you control all public entry URLs
• you can test every auth/payment/integration callback path
• you can tolerate rewriting HTML headers and redirects
• your app does not depend heavily on Bubble-generated absolute links being sacred
• you are okay debugging edge cases instead of expecting clean platform support
I’d avoid it if:
• this is a public-facing critical app
• SEO matters a lot
• there are lots of OAuth/payment/webhook callbacks
• multiple Bubble environments are involved and users may jump between dev/live
Though honestly it’s not worth the trouble trying to reverse proxy a Bubble app. Bubble apps are very sensitive when it comes to these things. It’s easier to just route paths instead. Some examples:
Create a subdomain that is Cloudflare proxied to work with Workers eg. services.domain.com
For one of my apps, Bubble handles redirects by using the 404 page as a catch-all and then redirecting users if it matches the path to a “redirect” datatype record.
Alternatively you can use Bubble’s 404 page to redirect users to a Cloudflare proxied subdomain to do a thing.
I tried once to reverse proxy my Bubble app at root domain. Not worth all the trouble.
You would avoid reverse proxying if SEO matter? That’s not correct.
It really depends on the path you chose, the explanation and guidance I provided is straight forward and in my testing has not caused any breaking issues at all. Apart from the email config, which I don’t use the native Bubble email anyways.
For one of my apps, Bubble handles redirects by using the 404 page as a catch-all and then redirecting users if it matches the path to a “redirect” datatype record.
This is far worse, terrible for SEO, and not at all meant for a production application.
• there are lots of OAuth/payment/webhook callbacks
This doesn’t change anything, as requests are only intercepted at certain routes, the rest are pushed upstream maintaining the same headers.
Respectfully, ChatGPT does not have this right at all There is technicality to this to understand it.
you control all public entry URLs
Not sure what this means? Who else would be controling your site’s entry points…
See what I mean? Understand and let people know about the limitations of an approach before recommending it.
From what I’ve interpreted, most power Bubble users do not use the native email integration from Bubble, and this is obviously meant for power users to begin with. Limitations are non-existent in my testing, and with my technical knowledge. I’ve worked a lot with reverse proxies and cloud infra.
Regarding this:
**I also found this from another forum thread:
Your logged in Users will have issues** - Anyone with a current active cookie will be stuck in limbo. They have a cookie connected to the original servers and you are now on new DNS servers. This creates the famous “can’t log out” loop. We tried to write some scripts to clear the cache or to logout all users, but basically failed and ended up apologizing and telling people how to delete their mysite.com cookies. (If any Forum users know how to do this better, we’d love to know).
It’s as simple as a clear cache/cookies. That’s a pretty normal thing to know how to do in 2026, there’s a button usually in every major browser.
What does “power user” have to do with native email integration? I use the API for custom emails but the native function is convenient too. Sendgrid is the biggest email provider in the world.
Not really reliable or worth much given that I had to be the one to call out an unintended side effect of doing this.
It’s not about “simple” or “normal.” That’s not a good experience for users. Do you have users?
Yeah I was thinking about doing this down the line, but without Cloudflare. Basically having the landing page be domain.com with Bubble being app.domain.com. Adding Cloudflare in front of domain.com seems like it would be the least headache.
It is but the project scope does not require any SEO.
All it’s pointing out is the additional precautions that need to be taken care of if you specifically decide to mask a subdomain behind root.
ChatGPT may not but I do. I just like having different perspectives when I come up with an opinion. Chat helps with that process.
You misunderstand. My response is specifically in the context of putting a Cloudflare in between Bubble’s own Cloudflare proxy by masking a Bubble app in a subdomain.
It’s in the context I mentioned above.
I don’t have a reason to watch your video as mentioned here:
Adding a reverse proxy to a Bubble app is not new and there are already many posts of by those who have tried. At the end of the day it comes down to what goals you are trying to achieve. That decides the implementation.
There is technicality to this to understand it.