The piece that is most likely to cause errors, caused errors. When we were notified of the breakage, we rolled back within 10 minutes. (~11 am EDT)
I’ve been working since then to pin down the exact set of behaviors that caused the problem, and once I found it, I corrected it and wrote automated tests around a really subtle edge case that was missed in our previous testing rounds.
I’m just as eager as you to get this feature live, which is why I’m posting an update. We’re going to do another round of deployment around 10 am EDT today (in ~8 hours).
If you’ll allow me to editorialize for a moment, I think we’re getting to the end of this road. It’s been a long journey, and you all have been very patient. I was perhaps over-optimistic to believe that we could hunt down every edge case in a single day (last Monday).
This change has, in my mind, been self-justifying. Cloudflare is a nice feature to have, but from where I’m sitting it’s almost secondary to the improvements in our network infrastructure that have and will continue to be made possible by virtue of this months-long deep-dive into the interplay between all the pieces that make up Bubble—especially your apps, which make all this possible and worthwhile.
While I’m running tests and waiting for any other bug reports to come in tomorrow, I’ll be putting the final touches on some documentation on how best to transition to the new system. If all goes well when the feature goes live (fingers crossed!), you’ll all have clear instructions on what to do to transition over.
It doesn’t need to be sent as a request to Bubble Support. For anyone who had a domain configured before final rollout, the checkbox will look like this:
I have a subdomain already redirected to my Bubble app with the A record… so app.example.com is redirected to 54.68.12.205.
I just contacted my domain provider (Siteground), and they told me an ANAME can only be used to redirect a whole domain, and not a subdomain. They then implied that I can do the subdomain redirect required with a CNAME.
Can you help clarify this for me?
Can I use a CNAME redirect for setting up Cloudflare with Bubble?
It is all a bit beyond my knowledge, and I don’t want my live app to be down a long time by getting this wrong!
As with @meinharttv we struggled with Cloudflare and Bubble and I would hesitate to recommend it to anyone using it beyond a CDN.
The flattening seemed very much beta. But we were forced down this path by the absolute refusal to allow CNAME whitelabeling on the Bubble side and could never get it to work reliably.
The “forcing” of the www seems odd, given that it is mostly ignored now.
We’re going to do another round of deployment around 10 am EDT today
The change is live.
The intent here is to detect any flaws in our routing code. I have verified that we have no regressions; we’re going to let this sit for a few hours until we verify that it’s completely safe.
I’m choosing to respond to you, but this is meant to address points from a number of posters.
I could talk about this stuff extemporaneously for hours, so this necessarily the briefest of overviews.
The original spec for DNS is 36 years old. The assumptions the designers made in 1983 haven’t stood the test of time. However, in order to support as many users as possible, we have to consider the lowest-common-denominator registrar first.
A records are the easiest records to work with, but they don’t scale without AnyCast.
CNAME records were never intended to be used as extensively as they are now, but many platform-as-a-service providers (like Bubble or Heroku) have built on top of the CNAME infrastructure to make their platforms as flexible as possible behind the scenes.
www vs bare: Users expect to be able to type either into their browsers to find your (and our, and anyone’s) sites. Address bars show less and less information every year; first, they dropped the protocol (http or https); next they stopped showing www.
No matter what’s happening under the hood, though, users expect your site to load on either address.
As of today, we’re supporting both schemes indifferently: if you enter your domain as www, we redirect calls to the bare domain to www and vice versa. But the DNS records still have to exist, or someone (your registrar, your DNS provider, us) has to generate the redirect so as not to split your traffic/SEO across two domains.
Configuring records: We want you to be happy on Bubble. Whatever we can do to make your experience work best for you, we want to get there together.
DNS configuration is routinely one of the most frustrating things our users deal with. When DNS is misconfigured, it often looks to our users like a platform outage, and much of the time the problem is out of our hands.
For instance, there’s a single DNS provider in Europe that does non-standard routing which breaks SSL for about a dozen customers on the Bubble platform. I spent probably 10 hours figuring out what was happening there, and the end result is “there’s not much we can do.”
With this transition, we’re trying to make the record configuration process as painless as possible, based on previous learnings. This is why we’re recommending new users use www-domains.
It’s tremendously difficult to write documentation that respects the reader’s attention while also taking into account even 80% or 90% of the possible variation they might face with external providers. (That’s not stopping me from trying!)
For everyone’s edification, if you have any questions about how to get your domain set up properly (however you choose to do it), Heroku uses a similar setup as we will be. In particular, this link describes how to get a bare domain configured to target a named record, as opposed to an IP address. If you choose to opt-in to Cloudflare before our own documentation is ready, that link should give you a good start setting up your own domain.
Hey @peterj thanks for your hard work on this! Just a note that at least on my settings panel I click the activate checkbox and then see nothing pop up below. I then can’t uncheck the box and have to refresh the page and when I do it comes up as unchecked again, not sure if I’m doing anything wrong.
Peter, I have a basic question. How do I know that this feature is enabled on my APP? I’ve checked the settings panel and couldn’t find any indication.
Thank you
This feature is available to you in Settings --> Domain/ email. If you are currently on a custom domain, you will see the checkbox that @jonathan.timianko described above, which will let you activate Cloudflare for your app.
Long story short, the way we surface information (errors, etc) to users changed recently, and I didn’t account for that post-validation. The success/failure messages you need to set up your apps aren’t showing up the way you need.
I’ve actually been watching our Cloudflare control panel, and I can see some of you activating the feature, but without the information I mentioned you’re not in a position to close the loop.
We are investigating an issue where when you click the Setup Cloudflare checkbox some apps get a message that Cloudflare is setup successfully instead of getting the necessary DNS records to actually set it up.
This is harmless, but will prevent you from completing the Cloudflare setup process.
We are looking into it and hope to have a solution soon.
My bubble app is currently set to a custom domain and cloud flare. Should I switch off my current cloud flare set up that i previously set up manually and then set up again via the tick box?
The current set up is giving me errors:
We’re going to do another round of deployment around 10 am EDT today (in ~8 hours).
