Migrating CloudBleed impacted static websites to Firebase Hosting

Posted by Jen Tong on February 24, 2017

So CloudBleed is a thing, and it’s a bummer for a lot of big websites. But, it’s also a bummer for countless tiny websites that use Cloudflare for Flexible SSL. You know, all those static websites for side projects and silly artsy things. Many of them follow this recipe:

This recipe is awesome for so many reasons. It’s on your own domain, CDN delivery just works, and it’s almost free: all you pay for is the domain registration. I used it a lot myself. But in light of CloudBleed, it’s a good time to consider other options. Here’s the recipe I’m pitching:

  • Static HTML site, likely generated by Jekyll (nothing changes here)
  • Hosted on Firebase Hosting
  • Domain mapped to a your custom domain name
  • Https provided by Firebase Hosting

Why Firebase Hosting

I’m biased (I work for Google), but honestly I don’t know of any other options for free static website hosting that also provide domain mapping and SSL. But here are some cool things about Firebase hosting anyway:

  • The Firebase part is free, so it won’t cost you any more[1].
  • You get real TLS, so you don’t have to feel dirty about using Flexible SSL any more.
  • You get redirects and rewrites!
  • You can lift-and-shift your site with minimal effort, and probably be done by later this evening.

[1] It’s free for sites under 1GB of stuff, and 10GB of traffic. This more than covers all my side projects.

Migration instructions

Oh? So I’ve convinced you to give it a spin? Follow me on a dinosaur filled adventure of static site migration as I migrate dinopacks.com, a silly art experiment with ~10 mb of HTML and images. Once in a blue moon it’ll get a spike of traffic from who knows where, but it generally matches the traffic patterns of my other side project websites.

The files for Dinopacks were previously hosted on Google Cloud Storage, but in an earlier incarnation the files lived on GitHub Pages. It also used Cloudflare Flexible SSL.

Migrating website data

There’s no reason your site can’t be published twice, so start by copying your website data to Firebase Hosting. Once you verify it works, you can move traffic over.

I was able to stick to the Firebase Hosting docs through the whole process.

  1. Go to the Firebse Console, and sign up if you haven’t already.
  2. Create a new Firebase project. You need one for each static website.

  3. This is where you could upgrade to a pay account, but if your site is low traffic like Dinopacks. The free Spark plan will work fine.
  4. Attempt to install (or in my case update) the Firebase CLI.

    $ npm install -g firebase-tools
    
  5. Fix your npm permissions, which always seem to get weird on macOS.

    $ sudo chown -R $(whoami) $(npm config get prefix)/{lib/node_modules,bin,share}
    
  6. Successfully install the Firebase CLI

    $ npm install -g firebase-tools
    
  7. Authenticate the Firebase CLI.

    $ firebase login
    
  8. Change into your Jekyll project directory
  9. Make a tiny change to your website, like adding an HTML comment somewhere. This is a marker you can use later to verify that all of your traffic is going to the new host
  10. Init Firebase hosting. You probably only need to diverge from the Firebase CLI defaults once: tell it that your public HTML is in Jekyll’s default directory, _site.

     $ firebase init
     🔥🔥🔥🔥🔥 🔥🔥🔥🔥 🔥🔥🔥🔥🔥🔥  🔥🔥🔥🔥🔥
     🔥🔥        🔥🔥  🔥🔥    🔥🔥 🔥🔥       
     🔥🔥🔥🔥🔥   🔥🔥  🔥🔥🔥🔥🔥🔥  🔥🔥🔥🔥🔥
     🔥🔥        🔥🔥  🔥🔥    🔥🔥  🔥🔥        
     🔥🔥      🔥🔥🔥🔥 🔥🔥     🔥🔥 🔥🔥🔥🔥🔥   ...
                
     You're about to initialize a Firebase project in this directory:
        
         /code/dinopacks.com/
        
     Before we get started, keep in mind:
        
         * You are currently outside your home directory
        
     ? What Firebase CLI features do you want to setup for this folder? Database: Dep
     loy Firebase Realtime Database Rules, Hosting: Configure and deploy Firebase Hos
     ting sites
        
     === Project Setup
        
     First, let's associate this project directory with a Firebase project.
     You can create multiple project aliases by running firebase use --add,
     but for now we'll just set up a default project.
        
     ? What Firebase project do you want to associate as default? dinopackscom (dinop
     ackscom)
        
     === Database Setup
        
     Firebase Realtime Database Rules allow you to define how your data should be
     structured and when your data can be read from and written to.
        
     ? What file should be used for Database Rules? database.rules.json
     ✔  Database Rules for dinopackscom have been downloaded to database.rules.json.
     Future modifications to database.rules.json will update Database Rules when you run
     firebase deploy.
        
     === Hosting Setup
        
     Your public directory is the folder (relative to your project directory) that
     will contain Hosting assets to be uploaded with firebase deploy. If you
     have a build process for your assets, use your build's output directory.
        
     ? What do you want to use as your public directory? _site
     ? Configure as a single-page app (rewrite all urls to /index.html)? No
     ✔  Wrote _site/404.html
     ✔  Wrote _site/index.html
        
     i  Writing configuration info to firebase.json...
     i  Writing project information to .firebaserc...
        
     ✔  Firebase initialization complete!
     $
    
  11. With that done, you should verify that your site works by going to http://<your project>.firebasepp.com. For example, I went to https://dinopackscom.firebaseapp.com to make sure Dinopacks made it up successfully.

Yay! The content is migrated. That was easy, wasn’t it? Now for the fun part: monkeying around in DNS.

Custom domain stuff

Assuming you want to preserve all those juicy inlinks, you need to migrate your domain name. This part will take a little longer.

  1. Go back to the hosting console for your project, click the Custom Domain button, and fetch the special TXT domain verification record.

  2. You can keep using Cloudflare for DNS, and their fast updates make this process quicker. Go to Cloudflare and add the TXT record. Use an @ to specify TXT records on the root domain.

  3. Wait a few minutes for the TXT records to propagate. You can verify them using the dig command. Correctly set up records should look something like this:

    $  dig TXT dinopacks.com
       
    ; <<>> DiG 9.8.3-P1 <<>> TXT dinopacks.com
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4328
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
       
    ;; QUESTION SECTION:
    ;dinopacks.com.			IN	TXT
       
    ;; ANSWER SECTION:
    dinopacks.com.		300	IN	TXT	"google-site-verification=xWOK-correct_XHorSe09bHSbaTTeryXStapLEA"
       
    ;; Query time: 53 msec
    ;; SERVER: 192.168.2.1#53(192.168.2.1)
    ;; WHEN: Fri Feb 24 15:21:15 2017
    ;; MSG SIZE  rcvd: 108
    
  4. Return to the Firebase Hosting console and click Verify.
  5. You have a couple options now: You can add a second TXT record and have a seamless transition (Advanced), or be lazy and accept a security warning for a few minutes (Quick setup). I opted for quick setup, and the warning was gone within a few minutes.
  6. Next, change your A records at Cloudflare to point to the IP addresses provided by Firebase Hosting. Make sure they’re configured to ‘DNS Only’, and not using the reverse proxy. If you have any CNAME aliases, remove them.
  7. Wait for them to propagate. Remember that marker you added up above? It’s a good way to know that things have migrated when viewed from mobile devices. This is also a good time to click around and make sure everything still works.

Cleanup

You’re done! Well, mostly. You could stop now, or you could take a moment to clean up all the clutter you left behind.

  1. Remove those TXT records that you added for domain verification. They’re benign, but they don’t need to be there any more.
  2. Delete the files at your old host. For me this involved deleting the Google Cloud Storage buckets that previously served my content. I could have done this with the command line interface, but I opted to do it from the console’s web interface.
  3. Update your deployment scripts to use firebase deploy.

What ifs?

Call me paranoid, but I’m always cautious about using free services. I do a ‘what if’ thought exercise on their limitations.

  • What if I get a huge spike of traffic and I exceed the Spark plan transfer limit?
    • Pay a few bucks to upgrade to a paid Firebase plan.
    • Or, since Cloudflare is probably still your DNS, you can enable their reverse proxy to reduce load. And yes, I realise the irony of that suggestion.
  • What if I run into a weird problem and I can’t find a solution on Stack Overflow?
    • Use one of your support tickets. (Something I actually did when migrating mimming.com, which had some legacy Firebase weirdness from past adventures.)

Conclusion

So now you’re migrated to another provider, you’re probably not paying any more, and you’re using proper SSL. Doesn’t that feel great? And if you decide you don’t like it, it’s just as easy to move to a different provider later.

If you found this tutorial helpful, let me know! If you have a better place to move your side project static websites, let me know that too. I’d love to share more options with people.

Update

I asked you all for other hosting recommendations, and provider got lots of recommendations: Netlify. I haven’t used them, but they look like another great option to consider.