If you don’t need any server-side HTML processing, you might not even need a “real” web server like NGINX—static websites can be hosted and served from GCP Cloud Storage buckets, a high performance and scalable alternative to traditional web hosting.
What Is a “Static” Website?
Static simply means that the content you serve does not change in response to requests. The best example of dynamic content is a server-side processing language like PHP, often used with frameworks like WordPress to fetch articles from a database in response to user requests. In this case, the HTML content is changed and customized before being sent to the user.
Google Cloud Platform, like AWS, offers a feature for this, allowing you to set up a Cloud Storage Bucket with a web endpoint, so you can use it as a web server for static content. There’s no instances, autoscaling, or NGINX configuration to worry about, and the bucket will scale up to meet any demand you send to it.
Pricing-wise, you’re simply paying the Cloud Storage costs for storage as well as bandwidth out, much like any other GCP service. You’ll also be paying the costs for the Load Balancer, which is used to deliver the content and provide HTTPS support. This isn’t free and charges per hour, plus ingress data processed, so you’re looking at an absolute minimum of about $20 per month. If you’re just looking to host a simple site for free, you may be better off using Firebase’s hosting platform , which has a generous free tier.
Of course, if you’re looking to run something like WordPress, you’ll need a real server, and if you’re building an application that needs a database, you’ll need a database server and API server as well. But, you’ll need those anyway, and if you can replace NGINX with a Cloud Storage bucket, it may save you some headache.
Setting Up Cloud Storage and Cloud CDN
Head over to the Cloud Storage Console to create a bucket.
Choose multi-region standard storage tier and uniform access control, then create the bucket.
The bucket is private by default. You can turn on public access from the permissions tab, by adding a new member, selecting “allUsers,” and giving it the Storage Object Viewer role. You’ll get a warning reminding you that this is allowing public access.
Once that’s done, you can copy over your website files manually, or use
gsutil rsync to sync an entire directory.
gsutil rsync -R public gs://bucketname
Your site should now be publically available, albeit under a subdirectory of
storage.googleapis.com. If you want to set up a custom domain with HTTPS, you’ll need a Load Balancer in front of it.
Head over to the GCP Networking Console, and click on “Load Balancing.” Create a new one, and select “HTTPS Load Balancing” as the configuration.
Set it as internet-facing, and under “Backend Configuration,” add a new backend bucket.
This basically just allows you to set the bucket name and enable Cloud CDN for this bucket if you’d like, which will cache content closer to users.
Next up, you can set the routing rules. You’ll probably be fine just routing everything to the one bucket, but if you want to store images or other media in a separate bucket, you can do so.
For the frontend configuration, set the protocol to HTTPS, and change the ephemeral IP address to a static one, which you might have to provision in the dialog that pops up.
You’ll, of course, need an SSL certificate to use your domain on HTTPS. You can provision one from Google for free or upload your own; you’ll need to link your domain, but once you do, you’ll be able to select it from this dropdown.
Click on “Review and Finalize,” and the Load Balancer will be created. You’ll need to configure your DNS to point towards the static IP you assigned to the load balancer.