[New feature] Cloudflare for all

Announcements New features
1

Hello everyone,

In the next couple days we’re going to be rolling out a feature that’s been in the works for quite some time: Cloudflare for all.

In the first phase, we’ll be making this available to all paid main cluster (non-dedicated) users, and over the coming weeks we’ll be expanding it to include all users, from free tier to dedicated.

For the uninitiated, Cloudflare is an edge network provider. In mostly non-technical terms, this means that they run data centers all over the world, close to your users. When a user makes a request, Cloudflare routes the request intelligently to the closest Bubble server or, if it can fulfill the request from a cache (for instance by serving up your static app code and images), it doesn’t even have to send the request to Bubble at all.

In completely non-technical terms, this means your pages are going to start getting faster. In many cases, a lot faster.

What does this mean for you?

If you’re going to be setting up a domain for the first time in the near future—not much. You will register your domain, enter it in the Bubble editor, hit submit, and be given a record to enter at your registrar (for instance, GoDaddy). Once you’re all done, you’ll get all the benefits of being on the Cloudflare network seamlessly, and gain the benefit of every new feature as they’re enabled.

For existing customers the process can be slightly more complicated.

To opt into our Cloudflare plan requires that you change your domain records with your registrar, and then both Bubble and Cloudflare verify that your domain is configured correctly. In our testing, this process typically takes about 2 seconds, assuming all records are configured correctly and that there are no errant domain records. (More on this below.) However, if the domain is misconfigured and cannot be verified, it could result in downtime.

For this reason, for legacy users (those who had a registered domain prior to the rollout), Cloudflare is opt-in.

A best-case workflow for legacy users might look like this:

  1. You currently have your custom domain, example.com, pointed to a Bubble record of the form 54.68.12.205 via an A record
  2. You verify that your registrar supports ANAME or ALIAS records
  3. You click the checkbox to opt-in to Cloudflare
  4. The Bubble server automatically issues an order to Cloudflare to register example.com as an app on our service
  5. When the order has been placed, you receive instructions to direct your domain name to the new endpoint at app.bubble.io
  6. You go back to your registrar and replace your A record pointing to 54.68.12.205 with an ANAME record pointing to app.bubble.io
  7. (Optional) Click “Check my settings” to re-trigger validation. If both Cloudflare and Bubble can find your app at app.bubble.io, then you’ll receive a message that you’re good to go, and everything should just work!

Of course, with something as complex as the domain record system, it’s likely your transition won’t be quite this easy. (This is, in fact, a big reason we chose to add this feature to the Bubble platform.)

What can you do to get the full benefit of this changeover, as smoothly as possible?

If your your app is at subdomain.example.com:

The most common examples of this type are of the form app.example.com. In this case, follow the directions above and you shouldn’t have any issues.

If you currently have a domain of the form example.com:

If you want to keep your domain as-is, without adding www, ensure your registrar supports ANAME or ALIAS records before opting in. (Note that GoDaddy, one of the most popular registrars, does not support ALIAS or ANAME records.)

If your registrar doesn’t support ANAME records, consider transferring your nameservers to a different DNS provider. (You can keep your current registrar.) Cloudflare’s free tier DNS supports CNAME records on bare domains, for instance, which is equivalent to an ANAME record.

If you’re comfortable switching to the form www.example.com:

Bubble will provide you with a CNAME record that looks like the following:

CNAME www app.bubble.io

Enter this at your registrar, and you should be good to go!

The downside of this is that this change may affect your SEO, and if your users have existing bookmarks to your current domain, they may need to update them.

Handling both www and bare domains

In either case, many of your users are liable to type in www.example.com when your site is hosted at example.com, or vice versa. Historically, we’ve redirected all requests from www to the bare domain. Once this feature is rolled out, if we receive a request for a bare domain and your site is located at www, we will redirect in that direction instead.

You will probably need some means of handling both types of records. We suggest that you use the CNAME/ANAME option, like this:
CNAME www app.bubble.io
ANAME @ app.bubble.io

(Here, @ is a common convention for referring to the bare domain.)

Here are some examples of how to configure ANAME/ALIAS records from around the web:

But again, different registrars will offer different solutions.
On Cloudflare DNS, your records might look like this:
CNAME www app.bubble.io
CNAME @ app.bubble.io

Read more here

Meanwhile, my registrar supports a feature where I can have www redirect to the bare domain, or vice-versa, without using ANAME records at all. Yours might as well.

15
15724×81 12.4 KB

We’ve worked hard to make this feature as painless as possible, and as always our Success Team and fellow forum users will be here to help you through the process of transitioning over, should you choose to do so.

Setting up custom domains is consistently one of the most error-prone processes our users deal with, and over time Cloudflare for all should eliminate a lot of these pain points, while making your Bubble apps faster!

46 Likes
2

Thanks for the awesome update and detailed information @peterj

For a client, we have been speaking for the last few months to move to a dedicated server, and to do so in a region outside of the “regular” Bubble regions, i.e. a “custom job”. I’ve had a dialogue with your team on this switch, and they’ve assured me this can be done with a few extra days of planning. The client’s main customer is isolated in a small, specific region, where it made sense to set up the dedicated server.

With this change, will that be unnecessary, or is there still something to be gained from placing the server closer to the main customer (I’m talking performance now, not compliance, etc).

3

For static assets (images, pages, app scripts) Cloudflare will make the second and subsequent loads after deployment faster for all users. But static assets are only half the story: dynamic content, such as user data, must still make a round trip to whatever server is hosting the database.

In a past job, I had to explain to users that you can’t beat the speed of light. We were trying to use a real-time app hosted on a server in Australia, from New York City. Even sending the smallest chunk of data a large distance incurs fixed costs on both sides: once, waiting for the message to arrive at its destination, and once waiting for the reply to make its way back. In situations like these where realtime performance is a concern, getting the server as close as possible to the end users will always result in better experience.

2 Likes
4

Got it! Thanks for the quick and clear response.

Also, congrats on the roll-out, another big step for Bubble!

5

Thanks for this feature @peterj - hope it will be really useful for Bubble users.
i have a question though,
what about those apps that are already going through CloudFlare using this approach Increase the Bubble page load speeds with Cloudflare
should we follow the same steps as described in your original post or there will be some changes there?
Thanks!

1 Like
6

Many of our users are using Cloudflare as a first step toward making their apps faster. That’s a big part of why we’re choosing to add this feature: a lot can (and often has) gone wrong for our users when adding Cloudflare’s performance features between Bubble and their own users, but when everything is configured correctly it makes user experience a lot better.

I can recommend using Cloudflare for DNS, since they provide easy bare domain CNAME record flattening. In this sense, the first part of that forum post is an excellent resource.

Some of Cloudflare’s performance features do not play nice with many websites. Rocket Loader in particular can produce a lot of pernicious errors that can be hard to track down.

As to other features, like Brotli—we have already turned many of these on, and there’s no additional performance gain to be had by adding Brotli to your own sites.

In general, we at Bubble will test out Cloudflare performance features to make sure they’re safe for everyone, at which point all users will be able to benefit from them as well.

1 Like
7

I think a video tutorial either uploaded on YouTube or in this thread would be of huge help.

Also, I had CloudFlare set up on a previous Bubble app of mine, however, the app was so dynamically oriented that I barely witnessed any differences in speed.

5 Likes
8

@peterj This is a great improvement! Saves server resources and speeds up apps for sure. Looking forward to try it out

9

I think a tutorial will be in order, for sure.

This project is just one major milestone on a long performance road. We started implementing it at the beginning of the year, and every step gave us cause to look at our existing network to identify how we could improve it to better serve our customers.

You can see this in the performance metrics from status.bubble.io. On the day we moved our main website to Cloudflare (aka the bubble.io rollout), our own latency was cut in half:

16
16850×211 15.5 KB

Without getting too technical, having Cloudflare as our edge network will give us the opportunity to make major improvements to our infrastructure transparently to our users.

8 Likes
10

Thanks, @peterj! Yes indeed, I feel the need for speed, and that’s my new crede, so your words I will heed without the need to breed, bleed, or smoke weed as I ride my steed…whateva… :crazy_face:

Ok, serious question now…

Just to make sure I’m crystal clear on this. I have registered a domain with a registrar but have NOT yet set it up in Bubble. Is my understanding correct that my registrar does NOT need to support ANAME or ALIAS records in that case?

1 Like
11

@peterj

This is great to hear! We have been waiting for formal Cloudflare support for quite some time as it’s critical for our apps. Can you speak to the process for us folks running on a dedicated instance who are already using Cloudflare? I know it’s a few weeks out but is there anything we can do to be planning for this change? Are there any changes in functionality that we should be aware of?

Thanks!

12

The big difference between people already running with a custom domain on Bubble and those who haven’t yet is that the former will have existing records, bookmarks, publicity materials, … with their bare domain listed. We don’t want to force our customers to reprint their business cards because our platform changed.

It’s common to use either a bare domain or www (not both) for branding purposes, and have the other redirect to your main address. That way, all links are canonical (for bookmarks, SEO, etc.). When you type “google.com” in your browser, you get redirected to “www.google.com”. By contrast, when you type “www.twitter.com”, you get redirected to “twitter.com”.

In the past, we stripped the www off customer domains, and gave out A records to everyone. So if you chose the domain “mycoolapp.com” and tried to set the domain as “www.mycoolapp.com”, we would redirect that to “mycoolapp.com”.

With this change, it will be easier to use an address of the form “www.example.com” because every DNS provider supports CNAMEs of the type we described. Since you haven’t yet configured your domain with your Bubble app, we recommend you plan to go with www once you’re ready to go live. You’ll still probably want some record for your bare domain, but that can often be redirected to www without using an ALIAS/ANAME at all.

1 Like
13

That’s exactly the behavior I DO want.

That’s exactly what I DON’T want. I want the opposite - i.e. what you apparently USED to do and what I’ve done with all my domains in the past.

So, the question is, can I do it the way I want? You said you “recommend” the other way, but I feel very strongly, for branding and other reasons, about using the bare domain. Is that possible when I’m ready to set up my domain?

(In my mind, “www” is superfluous and just necessitates additional letters and space everywhere it appears. I don’t want it. It’s so…1990’s.)

EDIT: And besides, every time I say the letter “w” three times in a row, I sound like a babbling idiot. :wink:

EDIT 2: I don’t mean to harp on this too much, but it’s important to me that what appears in the address bar does NOT have “www”, so redirecting from the bare domain to “www” is not an option.

3 Likes
14

Thanks @peterj for the detailed information, this is a major step and great news, I’ve been following up with bubble team regarding the cloudflare integration since early this year.

I have a question, how this feature will play out for SAAS apps that want to allow their customers to CNAME the app? so when you visit our customer domain will see our app.

See:

15

@peterj will this feature support any possible European servers bubble might have?

16

I understand your concerns. When these changes go live, you’ll be free to choose whichever option you prefer, but you may have to move your nameservers to a different DNS provider to find ALIAS/ANAME support.

A major weakness of using A records for websites with a global presence is that A records are fixed in place. If my server example.com is located at 123.456.78.90, which (let’s pretend) is an IP attached to a server in Virginia, no matter where my customers are located they will always be directed to the server in Virginia.

If instead I configure my site to CNAME www.example.com to server.example.com, then when a customer navigates to my website, my DNS servers can intelligently route them to the closest instance of server transparently.

So there are very real advantages to using CNAMEs. ALIAS/ANAME records are mostly a convenience layer over A records, and have most of the same weaknesses as A records.

1 Like
17

We know the steps that will need to happen for dedicated support, and dedicated will be easier in some ways and harder in others.

We will need to register your domain with Cloudflare in advance, and arrange for what is called “domain validation” using a different mechanism than we’re using for non-dedicated customers. As each domain is safely validated, you will be able to update your domain records and the traffic should start running through the Cloudflare network seamlessly.

If you’re running multiple apps (each with a custom domain) on a dedicated instance, we should have no issues switching them over one at a time. Everything else that your instance needs to function should just work, as well. (For instance, login, API workflows, …)

There are other network upgrades that we plan to tend to in time, but these will happen independent of the Cloudflare upgrade.

1 Like
18

This upgrade is a necessary step in the roadmap towards geographically distributed servers. I can’t speak to that timeline, unfortunately.

1 Like
19

We’re aware of the demand for better whitelabel support, and this feature will help make that possible, but there are other changes we will have to make to get whitelabeling to a place that is satisfying for everybody.

1 Like
20

If my app needs to scale and I decide to upgrade the plan to dedicated (from personal or professional), will that process be seamless? A big part of the appeal of the Bubble platform for me is not having to worry about the technical details associated with “scaling”. Will this be a simple option in my app or account settings?