Skip to main content

Applications Overview

This slice documents the operator-facing applications declared under lumie-infra/applications/**. These are day-2 tools that support development, analytics, cluster administration, and internal AI workflows; they are not the Lumie product workloads under applications/lumie/**, and they are not the security control plane under lumie-infra/security/**.

Scope and ownership​

Source paths​

PathRole
lumie-infra/applications/application.yamlArgoCD app-of-apps entrypoint for the whole applications slice
lumie-infra/applications/kustomization.yamlEnumerates the applications that belong to this slice
lumie-infra/applications/coder/**Self-hosted Coder control plane and workspace template
lumie-infra/applications/headlamp/**Kubernetes UI deployment values
lumie-infra/applications/openclaw/**OpenClaw manifests, secrets, PVC, and network policy
lumie-infra/applications/umami/**Umami Helm values and secret wiring
lumie-infra/security/teleport/agent/helm-values.yamlOperator access path for all four applications

Boundaries​

  • ArgoCD owns desired state for the application namespaces and the rendered workloads.
  • Teleport owns external operator access for all four applications in this slice.
  • Shared platform services such as Vault Secrets Operator, infra-db, cert-manager, and Goldilocks live outside this slice and are only consumed here.
  • Product services in applications/lumie/** are separate workloads even when an application depends on the lumie-dev namespace or shared database cluster.

Runtime map​

Access model​

All four applications are deployed without direct public ingress in this slice.

  • Coder is exposed as the Teleport app with public_addr: coder.lumie-infra.com.
  • Headlamp is exposed as the Teleport app headlamp.
  • OpenClaw is exposed as the Teleport app openclaw, with Teleport injecting the bearer token expected by the gateway.
  • Umami is exposed as the Teleport app umami.

That access contract is declared in lumie-infra/security/teleport/agent/helm-values.yaml, not in the application folders themselves.

Operational patterns shared by this slice​

  • Every ArgoCD Application in this slice enables automated sync, pruning, and self-healing.
  • Each namespace is labeled goldilocks.fairwinds.com/enabled: 'true' through ArgoCD managed namespace metadata.
  • Secret material is either rendered by VaultStaticSecret resources or delegated to chart-owned secrets that ArgoCD intentionally ignores.
  • None of these pages own troubleshooting content. The goal here is the standing contract: what is deployed, how it is reached, and how to verify it.

Common failure modes​

  • Teleport access breaks even when the workload is healthy, because the public access path is outside the application namespace.
  • Vault secret refresh or transformation errors leave workloads running with stale or missing connection credentials.
  • ArgoCD stays Healthy while an application-level dependency is broken, such as a bad database password or a broken OIDC redirect.
  • Applications backed by upstream charts can drift in rendered defaults after a chart upgrade even when local values files are unchanged.

Verification​

Use these commands to verify the slice without mutating cluster state:

kubectl get applications.argoproj.io -n argocd coder headlamp openclaw umami
kubectl get pods -n coder
kubectl get pods -n headlamp
kubectl get pods -n openclaw
kubectl get pods -n umami
kubectl get svc -n coder
kubectl get svc -n headlamp
kubectl get svc -n openclaw
kubectl get svc -n umami

Success means all four Argo CD Applications are present and Synced/Healthy, each namespace has Ready pods, and each service resolves to the workload expected by its detail page.

Pages in this slice​