Skip to main content

Umami

Umami provides Lumie's internal website analytics UI. It is deployed from an upstream chart, pointed at the shared infra-db PostgreSQL cluster, and exposed only through Teleport.

Responsibility​

  • Run the Umami web application in the umami namespace.
  • Store analytics data in the shared infra-db cluster, database umami.
  • Load HASH_SALT and database credentials from Vault-rendered secrets.
  • Expose a Teleport-routed ClusterIP service without direct ingress.

Source paths​

PathRole
lumie-infra/applications/umami/argocd.yamlArgoCD Application targeting namespace umami
lumie-infra/applications/umami/helm-values.yamlUpstream chart values for image, DB, probes, and resources
lumie-infra/applications/umami/common-values.yamlVault secret rendering and duplicate-object suppression
lumie-infra/security/teleport/agent/helm-values.yamlTeleport app entry for umami

Public surface and contracts​

SurfaceContract
Teleport appumami
In-cluster serviceumami.umami.svc.cluster.local:3000
DatabaseShared infra-db, database umami, user umami
Secretsumami-hash-salt and umami-db-app
Health endpoint/api/heartbeat for startup, liveness, and readiness

The ArgoCD app ignores data differences on the Secret umami-app-secret, which keeps chart-managed secret churn from reporting false drift.

Runtime flow​

Secret and dependency wiring​

  • umami-vss renders HASH_SALT from Vault path applications/umami.
  • umami-db-app-vss renders host, port, username, password, and URI for the shared PostgreSQL database from Vault path infrastructure/postgresql.
  • The upstream PostgreSQL subchart is disabled; there is no namespace-local database.
  • The checked-in image comes from the internal mirror zot.lumie-infra.com/umami-software/umami:postgresql-v3.1.0-arm64.

Failure behavior and operational risks​

  • A wrong database secret or missing HASH_SALT causes repeated application startup failures.
  • Probe success on /api/heartbeat is the quickest confirmation that the web app has booted and the route is live.
  • The memory limit was explicitly increased after prior startup OOM kills, so resource regression is an upgrade-sensitive area.
  • Because ArgoCD ignores only the data field of umami-app-secret, unexpected metadata changes to that secret still show up as drift.

Observability​

  • ArgoCD app health and pod readiness cover most day-2 verification.
  • There is no checked-in ServiceMonitor for Umami in this slice.
  • Application logs are the primary place to diagnose DB connectivity and migration-time failures.

Verification​

kubectl get applications.argoproj.io -n argocd umami
kubectl get deploy,pods -n umami -l app.kubernetes.io/name=umami
kubectl get svc umami -n umami
kubectl get secrets umami-hash-salt umami-db-app -n umami
kubectl logs -n umami -l app.kubernetes.io/name=umami --all-containers --tail=200
kubectl port-forward -n umami svc/umami 3000:3000
curl -sS -o /dev/null -w "%{http_code}\n" http://127.0.0.1:3000/api/heartbeat

Success signals:

  • The umami Argo CD application is Healthy and Synced.
  • The umami deployment is available, and the umami service listens on port 3000.
  • Vault-rendered secrets umami-hash-salt and umami-db-app are present.
  • GET /api/heartbeat returns HTTP 200, matching the checked-in startup, liveness, and readiness probe path.