Use Cloudflare JavaScript Workers to Deploy Your Static Generated Site (SSG)

Static Site Generators are becoming the de-facto way to build and deploy web applications that don’t require Server Side Rendering. These are apps with pages that don’t require an actual web server to dynamically render the content. The types of pages that do need a server are the often ones protected by an authentication wall. There may be other sites where the dynamic content is generated on the server for SEO.

Hugo, Gatsby, and NextJS are some of the most popular solutions in this space. They all build output composed of a set of files (HTML, CSS, JavaScript, Images) in a folder, and we can then serve them to users with a regular server (NGINX, Apache, etc.) or preferably via a CDN (Content Delivery Network) since we won’t need server business logic for this. Only a file storage that the CDN will use as origin.

Along with these artifacts, some static SPAs, especially apps developed with react-router, might require extra configuration. We can achieve this by redirecting all paths to a single file. This can be achieved on a Load Balancer or even with Cloudflare Workers itself.

In all these cases so far, we still need to store our files somewhere. AWS using an S3 bucket and a Cloudfront distribution has historically been a great way to go. The purpose of this post is to showcase another solution. Deploy directly to Cloudflare Workers using their latest Workers KV datastore.

I have to make note that Cloudflare Worker’s original purpose is to bring compute to the edge. A serverless platform. Deploying Static Sites is another use case supported thanks to the availability of Workers KV store.

What’s a Worker

A Cloudflare Worker is a piece of JavaScript code that runs every time you access a specific route on a website proxied by Cloudflare. The code is executed on every request before they reach Cloudflare’s cache. This means Worker responses are not cached (although requests made by the worker to other web services might be cached with the appropriate caching headers).

Workers are executed in a secure context so we can safely include secrets in it. Workers don’t have access to another Worker’s context.