Many current club websites are/were built with Joomla. Years go by and updates get put off: a template needs upgrading to the new major version, a plugin suddenly stops working, the PHP version runs out of support - and “just a quick update” turns into a whole afternoon of error messages. Sounds familiar? That exact pattern is what got me looking for a different approach for our club, E13.

The idea behind it is actually simple: instead of running a database and a PHP program on the web that constantly needs maintenance and hardening, our site gets “baked” once on every change and is then served as plain, finished HTML. There is simply nothing left to hack - unlike Joomla or WordPress, where hacked club websites are sadly a common occurrence.

So that this does not stay a toy for the technically minded, and the rest of the board can write posts without any prior knowledge, three building blocks come together:

The content lives as plain text files in a Git repository on GitLab. If you grew up with Joomla, you may not know Git yet - think of it as a logbook. Just like we record every QSO with date, time and report, Git records every change to our files: who changed what, and when. Nothing gets lost, you can always page back through history, and an accidentally deleted article is never really gone. GitLab is the place on the internet where this logbook lives - roughly like a Dropbox with a built-in logbook, and for a public project like ours it is completely free.

From the text files, Hugo then bakes the finished website. That happens fully automatically on GitLab as soon as someone makes a change - nobody has to run Hugo by hand.

And so that nobody has to touch the text files by hand either, I took a look at Sveltia CMS and set it up as a proof of concept right here on this site, at /admin/ - not as a finished solution. That is the part an editorial team would actually get to see: a form just like in Joomla - type a title, write the text, upload an image, click “save”. Nobody sees any frontmatter, YAML or Git along the way. Sveltia is compatible with the widely used Decap/Netlify CMS format, but written from scratch: it runs entirely in the browser, needs no server of its own, and talks directly to the GitLab API.

To make it clearer where things actually happen in this setup, here it is as a picture:


flowchart TB
  subgraph browser["Browser (editor)"]
    F["Form in Sveltia CMS
(/admin/)"]
  end

  subgraph gitlab["GitLab - fully managed"]
    G["Git repository
just text files (Markdown + YAML)"]
    O["OAuth login (PKCE)"]
    C["CI/CD pipeline"]
    P["GitLab Pages hosting"]
  end

  F -- "Login" --> O
  F -- "Save = commit via API" --> G
  G -- "Push triggers build" --> C
  C -- "Hugo builds HTML" --> P
  P -- "serves it" --> V["Visitor"]

The point of this picture: the only thing an editor actually touches is the form on the left - and whatever comes out of it is, in the end, always just a text file in the repository. Login, saving, building the site and hosting all happen entirely inside GitLab; there is no server of our own, no database backup and no update window that anyone would have to look after.

Under the hood, behind the form there is a single config.yml that defines which forms exist: one for blog posts, one for fixed pages like “About us”, and one for the homepage with its announcements. Every field - title, date, tags, the draft checkbox, images - is individually typed, so no jargon and no raw YAML ever shows up in the form. Login runs through a GitLab OAuth app using PKCE, so there is no secret password that would need to be stored anywhere. On save, in the background: a commit to the logbook -> Hugo bakes the site again -> one to two minutes later the change is live. Anyone who wants to test offline can even point Sveltia at a locally running Hugo server instead of GitLab.

The approach is not without trade-offs. Honestly: everything in the repository is publicly visible - including drafts and every single change, complete with GitLab username and timestamp. If we adopted this for the club, that would mean: no membership lists, addresses or internal minutes in the repository - that would still have to run over a different system e.g. a managed Nextcloud. In return we would get a transparency that fits the amateur radio spirit - anyone can see how the site is built, and any other club can copy the setup. And because the content is plain text files, we would not be locked into any single provider: should GitLab shut down at some point, everything can simply be moved elsewhere.

An important note on where things actually stand: none of this has been decided for E13 yet. Our club website keeps running unchanged, and which solution ends up being used is still being discussed by the board. What I put together here on my own site is one of several candidates on the table - not a done deal, and certainly not a finished migration plan.

If you would still like to see it live: I am happy to demo the setup at the next club evening, including “create a post and see it live two minutes later”, and I would welcome any opinions on it. That said, /admin/ only works for people with access to the repository - if you want to try it yourself, you can clone the repository, set up your own GitLab OAuth app as described in the README, and then try the admin interface on your own GitLab Pages.