Use Cases
Platform Teams
Give developers the self-service experience they keep asking for, on the cluster your security team already approved.
Your developers want to push code and see it running. Your security team wants everything on the cluster you already audit. Somewhere between those two positions sits a wiki nobody has updated since the last reorg, and a Slack thread asking who can deploy to staging.
Self-service for developers
Projects, environments, variables, logs and rollbacks in a dashboard, without a ticket or a pairing session.
Your cluster, your rules
Runs on the Kubernetes you already operate, with the network policies, quotas and admission rules you already enforce.
Auditable by design
AGPL-3.0, so your security team can read the code instead of taking a vendor's word for it.
The build-versus-buy trap
An internal developer platform is not a project, it is a staffing commitment. A portal gives you a catalog but no deployment path. A homegrown CLI works beautifully until the person who wrote it changes teams. Meanwhile the gap between what developers want and what the platform team can staff is where the shadow tooling grows.
Developers
Push code, want a URL
Lucity
The self-service layer you did not have to build
Your Kubernetes
Standard Helm releases and operators
What it puts on your cluster
Nothing exotic. That is the design constraint, because anything exotic becomes your problem at 3am.
Helm releases
One release per project and environment. `helm get values` works, and so does everything else your team already knows.
Operator-managed databases
PostgreSQL through a well-known operator rather than a bespoke controller nobody else has heard of.
Gateway API routing
The Kubernetes-native successor to Ingress, with certificates issued by the cert-manager you already run.
Labels, not a database
Platform state lives in Kubernetes objects and labels. There is no central database holding the truth hostage.
Because everything is standard, your existing tooling still applies. Policies, scanners, cost reporting and dashboards keep working on the workloads Lucity creates, because to them it is all just Kubernetes.
The architecture review answer
The question that decides these evaluations is rarely "does it work". It is "what happens when we want out".
- 1
Read the code
Open source under AGPL-3.0. No black boxes to reason about, no phone-home to explain to your CISO.
- 2
Run it where you want
Your cluster, your region, your compliance boundary. The hosted version exists if you would rather not.
- 3
Keep the workloads if you drop the platform
Eject writes out the charts and values. Applications keep running while you decide what replaces the dashboard.
- 4
Survive a platform outage
The control plane is not in the request path. If Lucity is down, the workloads it deployed keep serving traffic.
That last one is worth dwelling on. A platform that has to be healthy for your production traffic to flow is a new tier-one dependency. This one is not: it deploys and manages, then gets out of the way.