Open source · MIT licensed

Magnolia CMS on Kubernetes,
from one custom resource.

A Kubernetes operator that provisions a Magnolia author instance, N public instances, and a dedicated PostgreSQL cluster for each — with backups, point-in-time restore and Gateway API routing wired in.

View the source Install it Releases

What it does

You describe the deployment once. The operator reconciles everything under it — and keeps reconciling as the spec changes.

You write

One Magnolia custom resource
Image, instance count, storage
Hostnames, backups, logging

The operator creates

Author pod, PVC, ConfigMap, Services
N public pods, each with its own PVC
One PostgreSQL cluster per instance
HTTPRoutes and health checks

Scale the public count up and new instances seed themselves from an existing one; scale it down and the operator reclaims the pods, volumes and databases that are no longer in the set.

What you get

A database per instance

Every author and public instance gets its own PostgreSQL cluster, managed by CloudNativePG — not a shared database with a schema per tenant.

Backups and point-in-time restore

Continuous WAL archiving to S3, GCS or Azure, scheduled base backups, and restore to a timestamp, an LSN, a transaction or a named restore point.

Portable ingress

Standard Gateway API HTTPRoutes, so any conformant controller works — Istio, Envoy Gateway, NGINX Gateway Fabric, Contour. Tested on GKE's managed Gateway.

Per-instance routing

Optionally give every public instance its own hostname, so you can reach and verify a single instance directly rather than through the shared load balancer.

Your containers alongside

Add init containers, sidecars, volumes, environment variables and config sources per role or across the whole deployment, without forking anything.

Logging you can configure

JSON or pattern console output and per-logger levels straight from the custom resource, so log shipping works without rebuilding an image.

Install

Each release publishes its manifests to the project's package registry. Requires Kubernetes 1.27+ with the CloudNativePG operator installed.

VERSION=1.0.0
BASE="https://gitlab.com/api/v4/projects/magnolia-hamburg-public%2Fmagnolia-operator/packages/generic/manifests/${VERSION}"

# 1. The CRD. Server-side apply is required — the CRD embeds the
#    core/v1 Container and Volume schemas and is well past the limit
#    a client-side apply can annotate.
kubectl apply --server-side -f ${BASE}/magnolias.magnolia.hamburg-v1.yml

# 2. The operator itself.
kubectl create namespace magnolia-operator
kubectl apply -n magnolia-operator -f ${BASE}/kubernetes.yml

# 3. RBAC for the resources it manages.
curl -sSL ${BASE}/operator-rbac.yaml \
  | sed "s/namespace: REPLACE_ME/namespace: magnolia-operator/" \
  | kubectl apply -f -

Then apply a Magnolia resource. The repository ships a commented example covering every field, and the README documents the schema section by section — start there.

What this is, and isn't

Worth being direct about, so nobody installs it expecting the wrong thing.

You bring the Magnolia licence

The operator is MIT licensed. Magnolia CMS is commercial software licensed separately — you need your own licence and webapp image to run anything this operator deploys.

An independent project

Not affiliated with, endorsed by, or sponsored by Magnolia International Ltd. Built and maintained for real deployments, and shared because it may be useful to others running the same stack.

Infrastructure stays yours

It emits HTTPRoutes, never the Gateway, its TLS or its certificates. That cluster-level infrastructure differs per cloud and stays under your control.

Magnolia CMS on Kubernetes,from one custom resource.