[Logo for The C Shore Landing Page]
The C Shore

Plone vs Hugo

I've now built sites using a variety of static generation methods, participated in wikis and other's CMS systems, and was hosting a Plone instance (dynamic CMS), so I've decided to post a comparison of the different (and similar) trials and tribulations of using open source solutions for dynamic vs static web content management.

Table of Contents


For all the time it’s taken for me to get to writing this, I’m afraid it’s not going to be as informative and insightful as I would like. Nonetheless here go.


At present static web generation systems (such as Hugo) are better at a subset of the full range of deployments dynamic content management systems (CMS) such as Plone are capable of handling.


Access / Edit Controls

Static / Hugo

  • Single user / Small trusted group
    • While Hugo modules combined with using multiple repositories and access controls on git repositories could change this, at present most static web generation systems are built assuming full access to the content and layout tree.
    • Generally assumes that content going through the build system can be trusted and/or won’t break layout. (Hugo is changing somewhat in this regard with the switch to Goldmark as the Markdown engine, and now defaults to not allowing raw / potentially unsafe HTML in Markdown documents).

Dynamic / Plone

  • Usually designed so that relatively untrusted and/or unskilled at web design users can contribute content.
  • Plone (and other dynamic systems) usually have as fine or granular access controls as you want (e.g. individual users can be read only or full control on specific pages, and conversely groups can be global full control or read only).
  • Plone controls what HTML is allowed by contributors, and most other dynamic CMS systems likewise limit markup that could break site layout / design and/or contain a malicious payload.


Static / Hugo

  • Conducive to rapidly changing designs and requirements. As a single user / small group system the process controls and limits are basically what one enforces on oneself and/or to which the group agrees and follows. (This can be risk, by also allows for rapid changes).
  • The tools themselves are rapidly evolving and generally have active user and contributor communities.
  • Requires a site rebuild to add new content (however in the case of Hugo this is very fast).

Dynamic / Plone

  • Plone (and other dynamic CMS) are built to enforce and encourage larger group-oriented workflows. One can, as a single user post and publish immediately, but the initial setup still somewhat cumbersome due to the need to address the access control and process issues.
  • Tend to be more stable and mature, with less change across versions.
  • Plone at least doesn’t lend itself to to easy theming and/or branding, except within certain layout framework (because the generated HTML tends not to be very configurable).
  • Content is as added to the system once a contributor submits, and published one a reviewer approves (which can happen in one step for small deployments).

Server Resources & Security

Static / Hugo

  • As a static web site no CGI / WSGI / SCGI or other dynamic content is required. Where things like forms and commenting are required third party services are available to handle the dynamic part of content, or you can implement your own (which would require at dynamic serving capabilities).
  • Because the site is static serving tends to be very fast (and Hugo in particular includes tools to optimize images to further reduce load times), and large numbers of users can be served with small servers (and using a CDN works quite well).
  • Low risk of compromise as web servers without dynamic content tend to have few, or no, remote exploitable bugs.

Dynamic / Plone

  • Dynamic CMS involve some type of framework. Plone is Zope-based (which is a Python framework) which includes it’s own database. Other dynamic CMS system require an external database to manage the dynamic content.
  • As a dynamic system with logins, Plone (and other CMS) are at greater risk of being compromised through exploits, or weak user passwords, etc.
  • Because pages are generated as they are served, serving pages tends to be slower than a static system where pages are pre-generated and are available as fast the web server can read from the file system and push the results over the network.

Third Party Themes

Static / Hugo

  • Tend to have a large number of basic / minimalist themes but few full-scale themes (especially free ones).
  • However, rolling your own is easy for an experience web designer, and can be updated as needed.
  • As static sites tend to be more ad-hoc theming is likewise more ad-hoc and have few required use-cases.

Dynamic / Plone

  • Tend to have large numbers of themes (but many more paid than free).
  • Tend to be hard to change very much of the theme.
  • Tend to be difficult to create and/or have more pre-defined use-cases that are expected to be handled.


For a single designer or small trusted team static sites are much more flexible, takes fewer server resources, and have fewer security risks than their dynamic counterparts. For most other scenarios a dynamic CMS is what will have the fewest pain points.

Future Directions

Hugo and services like Netlify and Netlify CMS are changing the static vs dynamic equilibrium, and opening up new multi-user scenarios for static sites.

See Also