Deployment & Operations
ClavionX ships in three sizing profiles — Lite, Standard, and
Large — that trade off operational complexity against scale and
availability. Which one you pick determines how you deploy (Docker Compose
vs. Kubernetes/Helm), not which features you get: every profile runs the
same application code, gated only by a small set of capability flags
(eventTransport: polling vs. kafka being the main one you'll notice).
| Profile | Who it's for | Deployment mechanism | Rough scale |
|---|---|---|---|
| Lite | Evaluators, indie developers, home labs | Docker Compose only, single container per service, embedded/single Postgres, no Redis, no Kafka | ~500 sessions, ~50 req/s |
| Standard | SMB / departmental deployments | Docker Compose (docker-compose.standard.yml) or Kubernetes + Helm | ~10,000 sessions, ~500 req/s |
| Large | Enterprise / regulated environments | Kubernetes + Helm (GitOps via ArgoCD/Flux recommended) | 100,000+ sessions, tested at that scale |
A docker-compose.large.yml file exists too, but it's meant for local
development against a Large-shaped stack — a real Large production
deployment is expected to run on Kubernetes with an externally managed
Kafka, not Compose on a single host.
What differs between profiles
The application never branches on the profile's name — only on capability flags it derives from it. Concretely, moving from Standard to Large changes:
- Event transport — Standard uses outbox polling (no message broker required); Large adds Kafka and turns on the event-processor service.
- Replica counts and autoscaling — Standard runs
runtime-api/runtime-uiat a low fixed replica count with no autoscaling; Large autoscalesruntime-api(4–10 replicas),event-processor(2–4), andruntime-ui(3–6).control-plane-apiandcontrol-plane-uistay a singleton in both profiles — the control plane bootstraps from a lock-file/data-directory design that doesn't horizontally scale, and doesn't need to. - Datastore topology (Kubernetes only) — the
iam-platform-infraHelm chart'spreset: standard|largesetting governs whether itsmode: nativecomponents render as simple single-instance StatefulSets (Standard) or operator-backed HA clusters — CloudNativePG for Postgres, Strimzi for Kafka, a Redis operator with Sentinel for Redis (Large). The public interface (a{component}-connectionSecret) is identical either way; only what's behind it changes.
Manifest shape — Ingress, Service, NetworkPolicy, ConfigMap, Secret — is identical between Standard and Large; only capability flags, replica counts, and autoscaling ranges differ.
Where each profile is documented
- Self-Hosting — Compose vs. the Kubernetes/Helm three-chart model, what each chart installs, and the Connection Contract that lets the app layer stay agnostic to how a dependency (Postgres, Redis, Kafka, …) is actually provided.
- Monitoring — Grafana, Prometheus, Loki, and Tempo, for both the Compose and Kubernetes paths.
- Upgrades, Backup & Restore, Troubleshooting — how to roll out a new version safely, how backup/restore actually works, and known operational gotchas.
For how the platform's own services and caches interact once running, see Configuration Flow.