Many current club websites are/were built with Joomla or WordPress. 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, or the site eventually gets hacked. Sounds familiar? That exact pattern is what got me looking for a different approach for our club, E13.

The core idea: bake once, then simply serve it

The core idea is simple: instead of running a database and a PHP program on the web that constantly need maintenance and hardening, our site gets “baked” once on every change and is then served as plain, finished HTML. That removes exactly the server and the database through which club websites are usually hacked – and hacked Joomla and WordPress sites are sadly a common occurrence.

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

  • Hugo – bakes a finished HTML page out of plain text files
  • Sveltia CMS – the input form in the browser: title, text, image, “save”
  • GitLab Pages – stores the text files, builds the site automatically, and serves it

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.

What it looks like for the editors

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 test right here on this site, at /admin/. 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 has to see any frontmatter, YAML, Git or other technical details along the way. Sveltia runs purely in the browser, needs no server of its own, and talks directly to GitLab.

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


flowchart TB
  subgraph browser["Browser (editor)"]
    F["Sveltia CMS
(/admin/)"]
  end
  subgraph gitlab["GitLab - fully managed"]
    direction TB
    G["Git repository
just text files (Markdown + YAML)"]
    O["OAuth login"]
    C["CI/CD pipeline"]
    P["GitLab Pages hosting"]
  end
  subgraph browserb["Browser (visitor)"]
    V["Visitor"]
  end
  F -- "Login" --> O
  F -- "Save via GitLab" --> G
  G -- "Push triggers build" --> C
  C -- "Hugo builds HTML" --> P
  P -- "serves it" --> V

The point of this picture: the only thing an editor actually touches is the Sveltia CMS environment – 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 security update that anyone would have to look after.

A look under the hood

Under the hood, Sveltia CMS itself is defined by 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 defined, so no jargon and no raw YAML ever shows up in the form. Login runs through a GitLab OAuth app, meaning GitLab handles the login, and GitLab’s own access permissions determine who is allowed to do what. On save, in the background: a commit to the logbook → Hugo bakes the site again → half a minute to two minutes later (usually less) the change is live.

Working flexibly – and being honest about maintenance

The nice thing is that going through Git is very flexible when it comes to workflow: anyone who wants to can edit the site on their own machine first, look it over in peace, and upload the finished version later. For normal editorial work, though, nobody needs that.

That doesn’t mean zero maintenance, though: Hugo, the theme, and the pipeline naturally keep aging. The difference is that a missed update here doesn’t tear open a security hole, at most it just leaves a new feature on the table. The site still stands even if nobody looks at it for a year.

Trade-offs and advantages at a glance

The approach is not without trade-offs. I would run the repository publicly, and that means: everything in it is visible – including drafts and every single change, complete with GitLab username and timestamp. (Technically, a private repository would also work, but the openness here is explicitly intended.) For the club that would mean: no membership lists, addresses, or internal minutes in the repository – that would have to run over a separate 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 provider: should GitLab ever shut down, everything can simply be moved elsewhere.

Bottom line, this adds up to a system that solves several problems at once: usable by the board like an ordinary form, no technical background required – and for anyone who wants to dig deeper, full access to the complete source code and every single change in the repository at any time. It needs no ongoing maintenance: no server, no database backup, no PHP or plugin updates that anyone would have to look after. And because every member with access to the repository can use the form, keeping the site up to date no longer depends on one person or a dedicated website team – anyone in the club can write posts, not just whoever happens to know Joomla. Backup and undo come essentially for free: because every change is a commit in the logbook, any earlier version can be restored at any time, with no separate backup system needed.

A few more advantages only become apparent once you have worked with it for a while: hosting and building the site are completely free for a public project like ours. The attack surface shrinks to practically nothing, because there is no database and no public login form that could be hacked. And because every change is technically a commit, this could even be taken a step further: changes could be reviewed by a second person before going live (a merge request) – not something we need right now, but always possible.

And what if Heiko loses interest one day?

That’s the most important question with a proposal like this, and it’s entirely fair. With a classic club website, the honest answer is usually: the club ends up facing a server nobody has the password for anymore, a hosting contract nobody wants to cancel, a database nobody can read, and a handful of plugins where only one person ever knew why they were pinned to that exact version.

Here, what’s left after I step away is: a GitLab project with text files. No server, no hosting contract, no database backup, nothing running in my basement. Three things make this noticeably more robust, in my view:

The content outlives the technology. The posts are Markdown files – readable text with a few asterisks scattered around. You can open and reuse them in any text editor, even if Hugo, Sveltia, and GitLab all disappeared at once. That’s not true of a database dump.

Nothing depends on one person. The repository would belong to a GitLab group for the club, not to my personal account, and there would be several owners from the start. Anyone who needs access doesn’t have to reach me first to get it.

Nothing quietly decays. If nobody touches the technical side for a year, precisely nothing happens: the site stays online, stays secure, and stays editable through the input form. And even if someone breaks the build process while experimenting, the last successfully built site stays online – you can only break the next attempt, not the site that’s currently live.

What I don’t want to claim is that nobody will ever need to look after it again. At some point somebody will want a new feature, and then it takes someone who can work with Hugo. The difference is that this isn’t specialist knowledge. Hugo, Git, and Markdown are documented, widely used, and tutorials are plentiful – a hand-patched Joomla template with five years of history is the special case here, not the Hugo site. And if truly nobody can be found: the content is just files. You move it to another provider or hand it to an agency, without having to ask anyone for permission.

On top of that, the toolbox available today is a different one. Five years ago, anyone who wanted to make deeper changes to a club website really had to master the technology behind it. Today you sit down with an AI assistant, describe in plain language what should change, and have the proposal explained back to you. That this works especially well with this setup is no coincidence: a Git repository of text files is exactly the format these tools are at home in – they’re trained on millions of such projects and can read the whole site, instead of clicking through an admin menu. A Joomla installation, whose state lives in a database and in checked boxes, can’t even be handed to an assistant like that in the first place.

The real point here isn’t the assistant, though, but the safety net underneath it. Because every change lands as a commit in the logbook, it’s individually traceable and individually reversible. You can have a proposal built on a side track first, look at the result at your leisure, and only then adopt it – the public site notices nothing of this until the very last click. That’s exactly the difference: here, experimenting has no consequences. In the admin area of a database-backed site, every misstep is live immediately.

Where do things go from here?

An important note on where things actually stand: none of this has been decided for E13 yet. The system described here runs in production for this site, and for our club website I have put together an example at https://amateurfunk-im-alstertal.dh3iko.de (the repository is on GitLab). There you can see just how interactive a static site can be: recent posts, tags instead of complicated menus, images, and events with a calendar view and calendar import. All of that works without a database, just like it does with Joomla. 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 club evening on 21 July 2026, including “create a post and see it live two minutes later”, and I would welcome any opinions on it. That said, only people with access to the repository can look at /admin/ – 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.