Using zola serve for production hosting

Feature requests
1

Summary

zola serve should be suitable for more than just development server.

Motivation

I started to evaluate Zola for various small websites, and I like it a lot. My team is moving to host web application on Openshift, and so I wrote a S2I builder that take a git repo as input, build the website using zola build and producing a container ready to run on Kubernetes or Openshift as output.

For now, I am using nginx in the container, but since nginx do not like having the rootfs being readonly (and so requires some maintenance), I started to wonder if using zola serve would make things simpler. However, upon testing, i stumbled on 2 issues I will present now.

Prior art

I haven’t found much on the forum. However, looking at others static website generator, Hugo seems to have a range of options that allow to make it more production suitable, according to the project webpage.

Issues

Issue 1: Livereload.js injection

zola serve inject livereload.js in each page, and open a websocket. While the websocket can be blocked by firewalls, etc, it would be better if this could be disabled, since that would marginally reduce ressources usage, and complain from people about having to enable js.

Issue 2: Adding the port to base_url

zola serve interfere with base_url, by adding the port,and so the internal port used by zola serve is exposed in the generated HTML code. However, since our setup use a reverse proxy in front, the links are all invalid, since they point to internal.server:8080 when I set base_url to internal.server.

The port change behavior is needed for the development server, so it can’t be removed.

Proposals

A production hosting would requires to change theses 2 behaviors, or minimally, the 2nd.
There is 2 ways this could be present in the UI.

Add a --production switch

First solution is to add a switch --production, or --no-devel or something else. This would disable livereload, disable the watchers, disable the base_url correction and just serve the files using http.

This approach is easier to understand, would be more future proof. However, it would also mean having to define what is exactly “using in production”, and potentially be too opinionated for some use cases.

Add separate individual switch

Second solution is to add 1 CLI switch for disabling the base_url modification, and 1 for livereload.
This approach is more complex, but more flexible. If the code base grow more powerful, there is no need to be extremely opiniated, it can just be a switch and let people setup their production.

However, looking at the existing prior art , Hugo, there is a lot that can be added. Hugo server seems to have enough options for each letter of the alphabet.

As I didn’t read the doc on PR before coding, I already wrote part of the code for the base_url part. I was ready to submit a PR but noticed the message on Github.

Questions

  • is using zola serve for non development purpose something that would be in scope ?
  • what interface would make more sense ?
2

It is explicitly out of scope.