This post is based on my experience of hosting techccino.com . Part I gives you all the answers regarding hosting a static website on Google Cloud. Part II is a historical overview of how I got there. By static websites, this article envisages single-page applications created for instance with
create-react-apps , but it can applied to any static page with minor modifications.
Part I: How to host a static web page step by step?
For readers who are busy, here is how to do it. Warning: the full solution requires you to read a few external guides on the way.
There are two things this tutorial explains:
- How to host a dev version of the web page using Google Storage buckets;
- How to set-up the live website environment using Firebase Hosting.
The first point is rather important because anyone maintaining a live deployment must be able to make changes and test them online independently of the live version. Using Firebase Hosting is optional if search engine optimisation (SEO) is not relevant or the web page will be used for demo purposes mainly.
The first step in all cases is setting up a Google Cloud Platform account. You can start with Cloud Console (for Storage) or Firebase. The main prerequisites are a Google account and a debit/credit card. There is no difference between the route you pick because having access to one gives you access to the other automatically.
Hosting using Google Storage for dev purposes
One thing I like about Google Cloud is the quality of their manuals in general. For the basic use cases. they are pretty good.
This is the the manual for hosting static websites on Google Storage: https://cloud.google.com/storage/docs/hosting-static-website. Conceptually, the process consists of four simple steps:
- Prove to Google as shown here that you have control of the domain name you want to host.
- Let’s say the domain name is
mywebsite.com, create a bucket in Google Storage called
- Configure the bucket to act as a web page as explained here. For example:
Note: the entry for main page and not-found is the same, index.html. This way you can use browser side routing with libraries like
react-router-dom and ensure at the same time that visitors can still access URLs like
4. Configure your DNS provider to serve the content of the bucket as per the manual above. As a DNS provider I recommend Cloudflare because of the following cool features:
- Caching the content is great for static websites and reduces your bill for egress from the bucket.
- They provide useful stats about traffic to your web page, i.e. no need for web page trackers initially. Later on, when there is steady traffic through your web page knowing where people click can be relevant for further developments and web trackers become handy.
- The free tier of Cloudflare is pretty comprehensive and probably covers all your needs. If your web page is really popular, you probably have the money to pay for it.
Hosting the live web page with Firebase Hosting
You may be wondering why the approach above cannot be used to host the live web page as well. The main issue is that accessing directly any other path than the landing page, i.e. html.index, returns a 404 response. From a practical point of view, visitors are unlikely to realise it, because they will be still seeing the right content. Unfortunately, page crawlers like the big search engines will not index any paths with the exception of the home page because they will see the 404 responses. In commercial terms, that means no SEO for your website!
Hence, Firebase Hosting comes to the rescue.
- This is the getting-started manual: https://firebase.google.com/docs/hosting/quickstart
By default Firebase will generate two default URLs for your page:
where you can immediately see the deployed website.
2. Here is how to add your custom domain to that list: https://firebase.google.com/docs/hosting/custom-domain
3. Go to the Firebase to get the IP address for the hosted website and set up the DNS records in Cloudflare to point to that IP address as explained here https://firebase.google.com/docs/hosting/custom-domain#dns-records-cloudfare-label
Here is how the techccino.com records look like on Cloudflare
Note: the Cloudflare proxy status has to be set to
DNS only in that case. Then, the TLS certificates from Let’s Encrypt will be automatically managed by Google for you.
After setting up the DNS records, it will take up to an hour for Firebase to actually provision a TLS certificate for the custom domain. Be patient!
Upload the website using Firebase CLI. The Firebase CLI has a wizard for that. This is how to install the CLI on your computer: https://firebase.google.com/docs/cli#setup_update_cli
These are the steps to initialise the project locally:
firebase initin the folder where the static
- Select hosting in the wizard.
3. Compiled react apps are stored by default in the
build folder, which is your public directory.
4. All path requests must point to
index.html for static react website.
5. Final step: do NOT overwrite if there is an existing
Part II: How I got here
Brief attempt with WordPress
I opened my company in 2018 and I needed a website for it. Money was tight so I put something together using WordPress and hosted it on the smallest droplet (virtual machine) on Digital Ocean . The arrangement worked OK and it cost me back then $7/month, which was the cheapest I could find. There were a few drawbacks though:
- I was using only 10% of what WordPress offers because the website was static, i.e. no fancy news section, user area, etc.
- I was manually provisioning the TLS certificate and every now and then I would forget to renew it. Oops!
- Why was I paying for an entire virtual machine to run 24/7 when all what the Apache HTTP Server was doing was serving static files generated with WordPress?
- I had to keep WordPress up to date all the time.
As I said, none of this was a deal breaker for me but the whole set-up was a bit fragile.
Enter Google Cloud Storage
The idea is very simple:
- generate the static website with something like react-scripts or gatsby.js;
- upload the files in a bucket called my.website.com let’s say;
- if you prove to Google that you manage the domain
my.website.com, then the bucket can be used to serve the static content to anyone anywhere.
The cost of this approach is a few cents unless your page generates lots and lots of traffic.
- very easy to set-up if you follow this tutorial;
- the TLS certificates are provided by Google, so no need for any extra work there;
- it is incredibly easy to prototype and make changes. If you need to deploy another version, just create a new storage bucket and update the DNS records accordingly.
- it does not work so well with react-router-dom: any route, except the homepage, returns
404 Not Foundfrom the Google bucket because for apps with browser routing, the only document that needs to be served is
index.htmlSolution: set index.html as a response for 404 requests as well.
- I was using Google Domain Names for DNS, which was absolutely fine, except that it does not provide any stats about the website traffic. If the DNS provider receives a request every time someone wants to access your website, they should be able to report back the number of visitors at least.
Cloudflare to the rescue
I looked at many different options but Cloudflare was the best value for money I could find. Well I am using the free tier so no money at all and it comes with built-in analytics based on the DNS requests it receives for the website. I can immediately see the number of visitors over time and their country of origin. They also offer protection in case of attacks on your website.
Just to clarify, this is not to say Google or other providers don’t offer something similar, but I have found the Cloudflare platform incredibly clear and easy to use. I am a big fan of easy-to-understand UIs.
While writing this article I had another look at the Cloudflare platform and found two extra really nice features:
- automatically minify any static resources;
- the option to redirect mobile users to a sub-domain, optimised for mobile devices.
Not bad at all!
This tutorial emphasises simplicity and robustness, which are incredibly important when starting something new. Many developers focus on what comes next, e.g. adding Google Ads to your page to profile the 1,000s of visitors. But, when you are just starting, none of that matters because there are no visitors anyway.
Techccino’s aim is to help customers start on a solid footing so that they can keep building and expanding their apps and not be constantly hampered by unnecessary running costs and complexity.
My name is Nik Vaklev and I am the founder of Techccino Ltd | Data Visualisation and Serverless Apps