Building a Go-native CMS engine with themes, plugins, admin CRUD, SEO, and caching

Matt.G — Thu, 14 May 2026 15:59:28 +0000

Hi everyone,
I’m the author of GoPress, an open-source CMS framework and CMS engine written in Go.
GitHub: https://github.com/0xmattg/go-press

GoPress started from a very practical question I kept running into:
What if I want the authoring workflow and extension model of a traditional CMS, but I also want the deployment model, type safety, concurrency, and long-term maintainability of Go?

I have used WordPress for real websites, and I still think the core product idea behind WordPress is extremely strong: content models, themes, plugins, admin workflows, media handling, permalinks, SEO, and a broad extension surface. That abstraction has survived for a reason.

But for some self-hosted company websites, product sites, documentation hubs, editorial websites, and custom content systems, I often wanted something closer to a Go application: a compiled service, a clearer codebase, explicit interfaces, built-in caching paths, API-first content access, and a deployment model that feels more natural to backend engineers. That is why I built GoPress.

GoPress is not a line-by-line rewrite of WordPress, and it is not an argument against PHP. It is a Go-native attempt to preserve the useful CMS shape — content, themes, plugins, admin, SEO, media, APIs — while rebuilding the engine around Go’s runtime and engineering style. The project describes this directly in its README: it focuses on keeping the editorial experience and CMS extension model while gaining Go’s deployment, concurrency, observability, and maintenance advantages.

What GoPress is

GoPress is a composable CMS codebase for self-hosted websites and content applications.
It currently includes:

A unified content model
Theme-declared custom content types
Data-driven admin CRUD
A theme rendering engine
Hook and filter extension points
Plugin registration and deactivation
REST APIs and Swagger / OpenAPI documentation
SEO primitives
Sitemap and redirect support
Multi-level caching
Media upload and responsive image variants
Multi-site / instance-level configuration
Bundled themes and bundled plugins The intended use cases are things like company websites, editorial sites, product showcases, documentation hubs, and custom systems that want to keep a CMS authoring workflow inside a Go deployment model. The current stack is intentionally familiar to Go backend developers: Gin, GORM, PostgreSQL, Redis, golang-jwt, Viper + TOML, slog, go-i18n, Quill 2.0, and swaggo/swag.

Why I built it

Most CMS systems are either very mature but operationally heavy, or very flexible but not really designed around backend engineering constraints.
I wanted a CMS engine where:

Content models are explicit.
Themes are separated from the engine.
Plugins extend through interfaces and hooks.
Admin pages can be generated from registered content definitions.
Caching is part of the core path, not an afterthought.
SEO is handled at the framework layer.
REST APIs are available for registered content types.
A production deployment can be a compiled Go binary plus PostgreSQL, with Redis optional.
That last part matters to me. A lot of smaller self-hosted websites do not need a complicated distributed architecture. But they still deserve good internal structure, clean deployment, and a predictable extension model.
GoPress is my attempt to make that middle ground practical.

Some technical design details

1. Unified content model
The core content model is based around Content, ContentMeta, and a ContentType registry.
The framework keeps core types such as post and contact_message, while themes can declare custom content types through theme.toml. These theme-declared models can drive admin navigation, CRUD screens, REST API exposure, rewrite rules, template mapping, and menu icons.
For example, a theme can define content types like product, service, showcase, case study, or any domain-specific entity without requiring the engine to hard-code those concepts.
The goal is to keep the engine generic while allowing each site or theme to express its own content structure.

2. Config-driven routing and templates
GoPress uses theme.toml to define things like rewrite slugs and optional archive / single templates. These settings are used to drive archive URLs, detail URLs, sitemap entries, admin permalinks, and dynamic template resolution.
This is one area where I intentionally borrowed the “CMS mental model” from WordPress, but moved the implementation into a more explicit configuration-driven Go structure.
Themes render output, but the engine owns routing, querying, SEO, media behavior, admin behavior, and shared infrastructure. That separation is one of the main design principles of the project.

3. Hook and filter system
GoPress includes a hook event bus with actions and filters:

AddAction / DoAction
AddFilter / ApplyFilter

The hook system returns removable handles, which allows plugins to deactivate cleanly without leaving hidden runtime coupling behind.
This is important because plugin systems can easily become messy. My goal is to provide extension points that feel familiar to CMS developers, while still keeping the integration boundary explicit and maintainable for Go developers.

4. Admin CMS generated from content definitions
The admin CMS is data-driven.
Registered ContentType definitions can generate list and edit screens. The admin supports role-based access control with roles such as admin, editor, author, and subscriber, plus rich text editing, media picking, and drag-and-drop ordering.
This matters because I do not want every new content type to require a custom admin module from scratch. A Go-based CMS should still provide a practical authoring experience.

5. Built-in SEO layer
SEO is part of the core framework.
GoPress includes site metadata, canonical links, meta descriptions, Open Graph tags, JSON-LD output, sitemap support, multilingual sitemap transformation, redirects, and per-content SEO overrides through the bundled seo-extras plugin.
A lot of CMS projects treat SEO as something to bolt on later. I wanted it to be part of the engine from the beginning, because real company websites and editorial sites need SEO infrastructure by default.

6. Multi-level caching
GoPress has a built-in cache path with L1 memory cache, optional L2 Redis cache, graceful fallback when Redis is unavailable, and page-cache middleware.
The current README lists performance targets such as sub-millisecond page-cache hits, under-50ms first render without cache, 50,000+ concurrent connections, and 100,000+ QPS with cache hits. These are stated as architecture targets, and the project still needs reproducible benchmark scripts and public benchmark reports before a stable release.
I want to be very clear here: GoPress is still beta. I am not presenting those numbers as proven production benchmark claims yet. They are design targets for the architecture, and benchmark work is one of the areas I want to improve next.

7. Theme and plugin separation
GoPress has a BaseTheme runtime that gives themes config-driven URL resolution, archive and detail rendering, fallback hierarchy, and automatic SEO integration. It also provides a shared template function map with helpers such as buildURL, archiveURL, contentURL, seoHeadFor, menuByLocation, translation helpers, hook rendering, and responsive image helpers.
Plugins are designed to extend through the core boundary rather than directly depending on specific themes. Bundled plugins currently include:

multilang — WPML-style translation, menu translation, language-prefixed routing, and language-aware redirects
seo-extras — Yoast-style per-content SEO fields
code-snippets — site-level injection for head, body open, and body end slots The idea is simple: themes should own presentation, plugins should own extensions, and the core should be the integration boundary.

Some UI Preview

Current status

GoPress is currently in beta.
The core content model, admin CMS, theme engine, plugin mechanism, SEO layer, cache path, media pipeline, and bundled example themes are usable. However, the project still needs more production validation, benchmark coverage, migration guides, and security review before I would call it stable.
If you try it today, I would recommend starting with internal sites, company websites, documentation sites, or content-driven applications where you can validate your own traffic profile, editorial workflow, backup strategy, and deployment model.
This is an early public release, and I would rather be transparent about that than over-market it.

Quick start

Requirements:

Go 1.25+
PostgreSQL 14+
Redis 7+ optional
cwebp optional for WebP variants The local build flow is:

git clone https://github.com/0xmattg/go-press.git
cd go-press

go mod download
make gopress

./build/gopress serve

On first run, the web installer guides database setup, site bootstrap, and admin account creation. After startup, the public site is available at http://localhost:8080, the admin CMS at /admin, Swagger docs at /swagger/index.html, and the REST API at /api/v1/content.
GoPress also includes a small CLI named gopress. It scans themes/ and plugins/ at startup, regenerates the autoload package, and runs the server, so adding a theme or plugin does not require hand-editing imports.

What I would love feedback on

I am especially interested in feedback from people who have built CMS systems, WordPress plugins/themes, Go web services, self-hosted publishing tools, or internal admin platforms.
Some questions I am thinking about:

Does the content model feel flexible enough without becoming too abstract?
Are the theme and plugin boundaries clear?
Is the hook/filter design idiomatic enough for Go developers?
What would you expect from a production-ready Go CMS?
Which migration path would matter most: WordPress import, Markdown import, static-site import, or custom database import?
What benchmark scenarios would you consider meaningful?
Would you use this more as a CMS, a website engine, or a content framework embedded into another Go application?

Closing

GoPress is still early, but the direction is clear: I want to build a serious Go-native CMS engine for developers who like the CMS product model but prefer Go’s deployment and engineering characteristics.
It is not trying to replace the entire WordPress ecosystem. That would be unrealistic. Instead, it is trying to serve a narrower group of developers and teams who want a self-hosted, extensible, Go-based content system with themes, plugins, admin workflows, APIs, SEO, media handling, and caching in one coherent codebase.
If this sounds interesting, I would really appreciate stars, issues, pull requests, technical criticism, architecture feedback, or even just a quick “this part feels wrong” comment.
GitHub: https://github.com/0xmattg/go-press
Site: https://gopress.xyz (also powered by GoPress)
Thanks for reading.

DEV Community: Matt.G