Lamassu IoT DocsKubernetes self-managed
Choose an installation workflow and network architecture for Lamassu on your Kubernetes cluster.
Self-managed Kubernetes deployment
Run Lamassu in a Kubernetes cluster operated by your team. The Helm chart deploys the Lamassu services and their routing resources; you provide the cluster, persistent storage, identity provider, PostgreSQL, RabbitMQ and the network path used by clients.
Choose an installation workflow
| Workflow | Use it for | What it installs |
|---|---|---|
| Helm | Production and controlled environments | Lamassu services and Gateway API resources |
| Fastlane | Evaluation, demos, CI and small lab clusters | PostgreSQL, Keycloak, RabbitMQ, Envoy Gateway and Lamassu |
What the Lamassu chart provides
The Lamassu chart is an application chart, not a cluster bootstrap chart. It creates the Kubernetes resources that run and configure Lamassu, but it expects the platform services those resources depend on to exist.
| Area | The Lamassu chart provides | You provide |
|---|---|---|
| Lamassu applications | Deployments and StatefulSets for the UI and APIs, internal Services, ConfigMaps, a ServiceAccount, and optional HPAs and PDBs | A working Kubernetes cluster, compute capacity and access to the container images |
| PostgreSQL data | A pre-install/pre-upgrade job that creates the required databases and schemas, runs migrations and applies the authorization bootstrap | A reachable PostgreSQL server, credentials allowed to create databases and schemas, and backup/HA operations |
| Messaging | RabbitMQ connection configuration for the Lamassu services | A reachable RabbitMQ broker, credentials and its lifecycle |
| Identity | OIDC/JWT and external-authorization configuration, plus initial Lamassu authorization principals | An OIDC provider, realm/tenant, client, users, groups and roles |
| External routing | One Gateway, HTTPRoute resources, an EnvoyProxy configuration and Envoy security policies | Gateway API and Envoy CRDs, the Envoy Gateway controller, a GatewayClass, a load-balancer implementation and the external network path |
| TLS | cert-manager Issuer and CA Certificate resources; either a chart-managed downstream Certificate or a reference to your TLS Secret | cert-manager itself; for trusted TLS, a trusted issuer or a populated TLS Secret |
| Persistent application data | PersistentVolumeClaims required by the default local KMS and VA storage | A StorageClass, physical storage, backups and a shared/external backend when scaling requires one |
| Optional integrations | Configuration hooks for observability, AWS connectors and PKCS#11/HSM connectivity | The observability backends, cloud credentials and production HSM or external key service |
A Gateway resource is not a load balancer
The chart creates Lamassu's Gateway and routes. It does not install the Envoy Gateway controller or make the generated LoadBalancer Service reachable from your network.
Recommended for a small single-node VM
Use one Lamassu Gateway on ports 80 and 443 and let its HTTPRoutes dispatch traffic to every Lamassu service. Give that Gateway one externally reachable endpoint through the cluster load balancer, or forward traffic to it from an external proxy or NAT device. You do not need one Gateway per service.
How the deployment fits together
Clients
|
| DNS name or reachable IP
v
LoadBalancer, node port, or external proxy/NAT
|
v
One Envoy Gateway (TLS terminates here)
|
+-- HTTPRoutes --> UI
+-- HTTPRoutes --> CA, VA, KMS and device APIs
+-- HTTPRoutes --> authorization and workflow services
+-- optional route --> your OIDC providerThe chart creates one shared Gateway per Helm release. All chart-managed HTTPRoute resources attach to it. Envoy Gateway provisions the proxy data plane and a Kubernetes LoadBalancer Service for that Gateway.
The gateway.addresses value is only an address request to the Gateway controller. It does not make an IP routable, open a firewall, configure DNS or create NAT. See Expose the Gateway before setting it.
Platform requirements
- Kubernetes 1.24 or newer
- Helm 3.2 or newer
- Envoy Gateway 1.8 or newer and a
GatewayClass - cert-manager 1.14 or newer; the current chart renders cert-manager issuer and certificate resources
- persistent storage suitable for the selected PostgreSQL, RabbitMQ, VA and KMS configuration
- a load-balancer implementation or another deliberate path from clients to the Gateway
KMS deployments using the native PKCS#11 sidecar require Kubernetes 1.29 or newer.