How applications are deployed

The applications a Community Cloud runs live under k8s/apps/, and most of them in the cc-office namespace. Each one is split by what each piece is, so they can be applied in order and read one at a time:

Every file is a template rendered against cc.config.json, and every one is embedded in the installer:

What they share

• Databases are CloudNative-PG, never a chart's bundled one
• Storage is TopoLVM through cc-local-ssd-fast
• Certificates are cert-manager and Let's Encrypt
• Ingress is the Gateway API, served by Cilium's Envoy, through a listener on the cluster Gateway
• Domains come from values.domain.* in the configuration, so an instance is rehomed by changing one file

The applications

The shared namespace

k8s/apps/office/ holds what the cc-office applications share:

Twenty CRM

Authentik

Authentik's chart bundles its own PostgreSQL. Community Cloud turns that off and points it at CloudNative-PG instead — one way of running Postgres across the cluster is easier to back up, upgrade and reason about. Authentik is also the worked example of an application packaged as a plugin.

Mattermost

Headlamp

Headlamp.values.yaml holds its Helm values, and Headlamp.plugins.yaml the plugins it loads — including Community Cloud's own, built from cc-headlamp/ in the repository. Headlamp is available as a package:

"packages": { "headlamp": true }

Picoclaw

Picoclaw provides an AI chatbot interface, designed to integrate automatically with available MCP servers. The goal is full cluster control via chat — in particular, understanding issues at the cluster level and correlating different kinds of data.

Databases

CloudNative-PG is used for every Postgres in the cluster, including the ones charts would otherwise bundle themselves.

Generated credentials

Some of what the cluster needs is a password that nothing outside the cluster has any reason to know — each application's database role, for instance. Those Secrets can't be checked into the repository next to the manifests that name them, so the installer invents them.

A package declares what it needs, and the credentials are created between its chart and the manifests that refer to them. Each becomes a kubernetes.io/basic-auth Secret with a three-word username and a five-word password, hyphen separated — about fifty-five bits, and a phrase survives being read down a telephone in a way a string of punctuation doesn't.

A password is created once and never rewritten. Running an install again doesn't rotate the credentials half the cluster is already using. Nothing records what was generated, either — it exists in the cluster and nowhere else:

To rotate one deliberately, change it in the Secret — or delete the Secret and install again for a fresh one. The database role's password follows within a few seconds, so anything holding a live connection will need restarting. That depends on the Secret carrying the cnpg.io/reload: "true" label, which is how CloudNative-PG knows to watch it.

AI inference

k8s/ai/vLLM/vllm-amd.yaml serves a Mistral-7B model with vLLM on AMD MI300 GPUs via ROCm, with host network and IPC, 8Gi of shared memory, and a Hugging Face token from the hf-token-secret Secret. It's exposed as a ClusterIP service on port 80, and its model weights live on the volume in vllm-amd-pvc.yaml.

It's scheduled onto nodes labelled node-role.kubernetes.io/worker-gpu, which the installer applies automatically to any node it finds a compute-capable GPU on.

Custom resources

Community Cloud defines two custom resources of its own, in k8s/crd/: