> In our case, the SSG tool is Jekyll, so adding its entire Ruby toolchain would defeat the purpose of using NGINX: being as lightweight as possible. Additionally, this huge image would create more attack surface. So, we quickly eliminated this option.
I don't think they understand how SSG works. You generate the site locally and then publish the artifacts. Its not like Jekyll is running on their server. There are also lighter weight SSGs, like Hugo. You can also run Jekyll on an alpine image for CI/CD and it is pretty small. My Hugo Alpine image is a mere 10MB. Once it is cached by CI/CD then it isn't being re-downloaded.
I think they do understand how ssg works. The issue they’re trying to solve is how to inject env-specific configuration at runtime. Regardless of which ssg you use you still need a way to vary these values at runtime. I don’t think using the ssg itself is a very efficient solution. Things like envsubst work well to template env variables into static assets or server config at image startup.
The issue is not so much about Jekyll vs. Hugo, because in our situation we also had to include other renderers like Graphviz, which bloats the build image considerably.
