Template-based static site generators and Cloudflare Workers

Smashing Magazine featured an article, Going Serverless with Cloudflare Workers by Leonardo Losoviz. He mentioned about static site generators like: Jekyl, Hugo, or Gatsby. I’m not sure if Leonardo, in a general sense, just correlated these platforms with serverless approach to hosting or if the workflows of those static site generators are doable in CF Workers.

The deployment normally would look like this:

  1. Static generator will build site. Content will be sourced from a database or third-party APIs and generates static html files and other assets.
  2. The static files including html are hosted via CDN.
  3. If there are code changes go to number one.
  4. If there are content changes go to number one.

Normally the building process and deployment are done manually from a local machine. There are cloud providers that can do the rebuilding process automatically via webhooks or timed event triggers, e.g: periodic batching after authors have finalised a number of articles for publishing to the web.

I’d like to know what sort of topology would be involved if these processes were to be done with Cloudflare CDN and Cloudflare Workers. I understand that bit that Workers can be used as API gateway and executing JS functions but getting up the whole website running via workers is a blurry. So here are my questions:

  • Would Cloudflare Workers platform be a one-stop shop place to host the pre-build files and deploy a website (as described above)? No?

If the answer to the above is no:

  • If we have to host the static files outside of Cloudflare Workers (example here), and when content is pulled from the originating server – will they be automatically cached in CF’s CDN?
  • In relation to the first bullet point, will Page Rules then kick in?
  • Can you please confirm my understanding that we can mix api and website calls in one worker script?

Appreciate your thoughts. Please be kind, I’m new to serverless approach. :slight_smile:


Workers have infinite possibilities from apps, websites, data manipulation, even content moderation, it is up to the developer creativity.

One case I use is to generate content with Hugo, push it to KV, then the Worker will guarantee the URLs trigger the right content from KV, with a mix of cache and global variables to optimize cost.

At this stage, the blog is fully geo-agnostic, ready to scale.

KV makes a great static site file hosting tool – our tooling is still catching up, but Workers + KV has been a very capable tool for hosting Hugo/Gatsby/etc sites: we’re actually using it for our docs and landing page right now! I’ll have a write-up coming soon about that :slight_smile:


@signalnerve Thanks Kristian.

I’m researching at this stage and not writing code as yet. I need to visually comprehend in my head the nuts and bolts of the infrastructure before I decide where to go.

First, It looks like I would not be able to do automatic batch rebuilds (build triggered by an API call) in the cloud whenever there are content changes only and I have to do this elsewhere. Thus the “one stop shop question.” I’m not using Gatsby (not Hugo). The way I understand CF Workers (not KV)) limit number of script files we can upload. So I’ll cross that out from my list then.

So I just saw this announcement: “Today, we’re excited to announce Workers KV is entering general availability and is ready for production use!”. It looks like we can store binary files already. I get the idea of gifs used as an example in that article. Looking at the gatsby dist directory after doing a build, how do I translate the files and nested folders in KV?

{ "<filename>" : "<path structure> , <binarydata>"}

Is the above correct? So without the tooling stuff you mentioned, would this mean I have to iterate my public directory, it’s subdirectories and files – then bulk write them to KV (100 MB, 10,000 key limit per bulk write).


If I were to radically reduce costs, having to do the build outside of CF doesn’t defat the purpose. Would having the files residing at source be better and have CF cache all files instead? I’m guessing there will still be differences in performance when clients access web pages?

For the docs site, the key is the whole path + filename. So for example, consider https://workers.Cloudflare.com/docs/quickstart/cli-setup/index.html; this page has a KV entry whose key is quickstart/cli-setup/index.html, and the value is the HTML contents of the page.

1 Like

oops, yes, sorry! I meant the semicolon purely as an english thing, not as part of the URL. Thank you!

1 Like

You are, ofc, quite welcome.

(Attachment publicKey - [email protected] - dbd0a5f5e3cc2e74e9570c13d574c382305cd5fe.asc is missing)

Did you publish write-up already?


Not yet, unfortunately! We’re waiting for a few things to land in Wrangler that will make it a lot easier to manage Workers KV, including static files. Hope to have more on this soon - I’ll definitely post in the forums when it’s out!


It has been a while and no updates to this thread. Much appreciated if someone from the Cloudflare Team can please provide a little more info for how this might work for newbies like me and others. Thanks.