Epic: offer a simple open-source headless CMS for client websites #4927

🤖 Generated by the Agentic Engineer (interactive Claude Code session)

Problem

Business clients who get a website from Devantler Tech ask to update its text and data themselves. Today every content change goes through the maintainer as a code change. The platform offers no content-management service, so each change costs his time, and clients wait for it.

Goal

Offer one popular, simple, open-source headless CMS as a platform capability. A client site built by Devantler Tech can let its owner edit text, images and structured data, and the site picks the change up without a code change by the maintainer.

The maintainer wants it simple: not a full website platform such as Umbraco or WordPress, but a small headless CMS that self-hosts well on a cloud-native Kubernetes cluster like this one.

Selection criteria

• Open source under an OSI-approved licence for every feature we use. Source-available or revenue-capped licences do not qualify.
• Popular and maintained: a large user base, regular releases, and an active upstream.
• Simple to run and to use: a non-technical client can edit content after a short walkthrough, and the platform side is one small workload with few moving parts.
• Cloud-native self-hosting: an official container image (amd64 and arm64), stateless pods, and configuration through environment variables or files. An upstream Helm chart is a plus. State lives in CloudNativePG Postgres or in Git, plus S3-compatible media storage, so existing backups cover it.
• Fits our sites: works with Astro (devantler.tech) and SvelteKit (client sites). Publishing a change triggers a rebuild or is read at request time. Content can be Danish and English.
• Per-client isolation: each client sees and edits only their own site, through separate instances or a proven tenancy boundary. Their editor logins are separate from platform SSO.
• Fits the platform's guardrails: Kyverno policies, network policies, Kubescape posture, and the GitOps deployment flow, without blanket exceptions.

Candidates to evaluate

Not a decision; the first child issue settles it. Stars and licences as GitHub reports them on 2026-10-15.

The main trade-off to settle:

• Git-based: no database, versioned content and simple backups. Editors need a login that can commit, and changes go live after a rebuild.
• API-based: logins live in the CMS and changes are live at once. It adds a service, a database and media storage to run per client.

Planned increments (child issues)

1. Spike: choose the CMS. Shortlist against the criteria, prototype the top two, and record the choice and its reasons as an ADR in docs/adr/.
2. Deploy the chosen CMS as a platform capability. Manifests, backups, network policy, posture checks and documentation, behind a default-off switch until a client uses it.
3. Pilot with one client site. Connect a real client site, let its owner edit a page, and confirm the change goes live. Gather the owner's feedback.
4. Make it repeatable. Onboarding steps, or tenant-template support, so the next client site gets a CMS in minutes.

Increments 2–4 are filed once the spike has chosen, because their shape depends on the choice.

Acceptance criteria

• An ADR records the chosen CMS, the criteria results and the rejected candidates.
• The CMS runs on the production platform, isolated per client, with its state backed up and restore tested.
• At least one client site's owner has updated their own content end to end, without the maintainer changing code.

Out of scope

• Full website builders or page-layout platforms (Umbraco, WordPress and similar).
• E-commerce, payments and user accounts for site visitors.
• Hosted SaaS tiers of any candidate.

🤖 Generated with Claude Code