There seems to be some differences of opinion among members regarding the Production use of Hugo Server.
Some people state openly that Hugo Server should not be used for “Production” and others have described the use of Hugo Server in Production as an important feature. Clarity on this topic is important for users planning implementations.
The built-in Hugo server is meant for development; it works fine in production, but we have deliberately labeled it as a dev server to prevent having to support it in production and adding production like features. Nginx or similar should run fine on Docker.
I personally believe there are many situations where Hugo Server can be used in “Production” if the servers limitations are understood ( like logging and ssl ). I also think billing hugo as a standalone single executable server Production has very strong appeal and should be promoted and supported.
I would consider the chronology of your references; e.g. a lot has changed since 2015.
I would then consider that all posts on here are written in the context of individual experience, use case, and expertise; therefore, dissonance, at least to some degree, is inevitable.
I’m deferring to @bep since he is the maintainer of the project—and for future reference, if my post conflicts with his, I would recommend you rely on his Hugo opinions rather than my own—but my understanding is that Hugo’s built-in server is fundamentally a dev server and that production use comes tagged with YMMV and caveat emptor.
With static sites, you have innumerable hosting/serving options. Is there any reason you want to rely on Hugo to provide features you can easily get elsewhere for free?
There are also many static site generators. https://www.staticgen.com
The trick is to pick the one with the most/best features based upon the system design requirements.
I can think of many reasons and use cases for wanting to run the same server in dev and prod. Or deploy Hugo into some sort of embedded design.
But if that is not recommended, it needs to be stated as it will affect feature requests, future development direction and options for architects and systems engineers.
Yes Harp for one. There are others listing this feature.
Harp is production-ready. By specifying an environment variable, extra LRUcaching is added to make your site run even faster.
I invite you to Google CI/CD, Microservices, embedded systems delivery and Agile. Then imagine how Hugo Server could possibly be implemented in such a way that it is more important than a tool on someone’s laptop.
To make Hugo ready for production serving, effort like that of caddy, nginx, Apache would be needed. It doesn’t make sense to pull a small team’s attention from the main point.
Haha, I work for a digital agency. I’m pretty familiar with CI/CD, Microservices, embedded systems delivery and Agile and have worked in (digital) publishing for a decade. I was hoping you could substantiate your argument w/r/t Hugo’s server being a deciding factor in picking an SSG since, to me, it seems like it’s exceedingly easy to work around. I’m with @RickCogley on this one.
It would also be quite naive to think that hugo server is a safe webserver compared to software specifically designed as webservers. Especially considering that Bep sees hugo server as a development server.
Harp is not a production-ready server if I look at their issues. It does not support Gzip, no CORS, never got SPDY support, doesn’t look to have HTTP/2 nor SSL support.
I was hoping you could substantiate your argument w/r/t Hugo’s server being a deciding factor in picking an SSG since, to me, it seems like it’s exceedingly easy to work around. I’m with