GetStackLens Helm Chart: Early Testing — Install It, Break It, Tell Us

We've been running GetStackLens internally with Docker Compose during development. That works fine for a single machine — one command, everything starts. But Docker Compose is not where teams run production infrastructure. Kubernetes is.

We knew that if GetStackLens is going to be self-hostable for engineering teams, it needs to meet them where they already operate. So before we open access more broadly, we wanted a proper Helm chart in place — not an afterthought bolted on later.

The stacklens-platform Helm chart is now out for early testing. It works — we're running it ourselves — but it hasn't been through the full gauntlet yet: different cluster configurations, different ingress controllers, edge-case secret management setups, mixed cloud environments. That's what we're asking for help with.

If you're running Kubernetes and want to be one of the first to try this: this post is your guide. We want to hear what breaks.

What We're Testing

The chart is at version 0.2.10. Core functionality is solid. What we haven't covered yet:

• Clusters with non-nginx ingress controllers (Traefik, HAProxy, ALB)
• Installations with external Secrets management (Vault, External Secrets Operator, Sealed Secrets)
• Air-gapped environments that can't pull from GHCR directly
• Clusters with strict PodSecurityAdmission policies
• Multi-tenant namespace setups

If any of these match your environment, your feedback is especially useful. We want to know what breaks before we stamp this stable.

What the Chart Deploys

The stacklens-platform chart is what you run on your own cluster today — the self-hosted surface is Identity, FlowOps, Gateway, and the UI:

Each service is independently togglable. The gateway discovers the other services by in-cluster Service names by default, but you can override with full URLs if you're running services outside the cluster.

PostgreSQL and Redis are optional bundled dependencies via Bitnami subcharts. Both can be disabled in favour of your own managed instances — which is the right call for anything beyond a test install.

Try It: External Postgres + Redis

If you have PostgreSQL and Redis already, point the chart at them:

helm install stacklens \
  oci://ghcr.io/getstacklens-ai/helm/stacklens-platform \
  --version 0.2.10 \
  --namespace stacklens --create-namespace \
  --set ingress.host=app.example.com \
  --set secrets.identityDb="Host=your-pg-host;Database=stacklens_identity;Username=stacklens;Password=..." \
  --set secrets.flowopsDb="Host=your-pg-host;Database=stacklens_flowops;Username=stacklens;Password=..." \
  --set secrets.redis="your-redis-host:6379" \
  --set secrets.jwtSecret="$(openssl rand -base64 32)"

The chart creates a Kubernetes Secret with these keys:

• ConnectionStrings__IdentityDb
• ConnectionStrings__FlowOpsDb
• ConnectionStrings__Redis
• Jwt__Secret

These are injected as environment variables into each deployment. If you manage secrets externally (Vault, Sealed Secrets, External Secrets Operator), set secrets.existingSecret to your existing secret name and the chart will skip creating one. We'd specifically like to hear how this path behaves in practice — it's one of the areas we have the least real-world data on.

Try It: Bundled Postgres + Redis

For a quick spin-up with no external dependencies:

helm install stacklens \
  oci://ghcr.io/getstacklens-ai/helm/stacklens-platform \
  --version 0.2.10 \
  --namespace stacklens --create-namespace \
  --set postgresql.enabled=true \
  --set postgresql.auth.postgresPassword="$(openssl rand -base64 16)" \
  --set redis.enabled=true \
  --set ingress.host=app.example.com \
  --set secrets.jwtSecret="$(openssl rand -base64 32)"

When postgresql.enabled=true, connection strings for Identity and FlowOps are generated automatically — no need to supply them. Same for Redis.

This path is explicitly for testing. PVC-backed Postgres in a pod is not a managed database. Don't rely on it for data you care about. Use it to verify the install works end-to-end, then migrate to a real data store before you do anything meaningful.

One Thing We Found the Hard Way

Bitnami subcharts — Postgres, Redis, and others — read from global.imageRegistry. If you set that value, Bitnami will try to pull its images from your registry. We initially put ghcr.io/getstacklens-ai in global.imageRegistry. This caused Bitnami to try to pull ghcr.io/getstacklens-ai/postgresql:.... That fails immediately.

The fix: StackLens app images live under a separate images block that Bitnami never touches:

images:
  registry: ghcr.io/getstacklens-ai
  tag: latest
  pullPolicy: IfNotPresent

We never set global.imageRegistry. Bitnami pulls from Docker Hub. StackLens pulls from GHCR. No collision.

Sharing this because it's a non-obvious trap that will catch anyone building Helm charts that mix their own images with Bitnami subcharts.

OCI Publishing

The chart is published as an OCI artifact — no traditional chart repo, no helm repo add step:

oci://ghcr.io/getstacklens-ai/helm/stacklens-platform

You reference it directly in helm install or helm pull. To inspect the chart before installing:

helm pull oci://ghcr.io/getstacklens-ai/helm/stacklens-platform --version 0.2.10

This gives you the chart tarball locally. Unpack it, read the templates, verify nothing unexpected before you run it.

Snapshot Builds

Every merge to main on the platform repository triggers a snapshot chart publish. Version format:

0.0.0-dev.<12-char-sha-prefix>

The images.tag in the chart is pinned to that commit's SHA. To install latest main:

helm install stacklens \
  oci://ghcr.io/getstacklens-ai/helm/stacklens-platform \
  --version 0.0.0-dev.abc123def456 \
  --namespace stacklens --create-namespace \
  --set ingress.host=app.example.com

Use semver releases for anything stable. Snapshots are for teams following active development or running integration tests against the latest platform code.

Values Reference

Full defaults are in values.yaml.

Known Gaps (Honest)

A few things that aren't fully baked yet:

• TLS automation — currently you wire up TLS via ingress.tls manually. cert-manager integration is on the roadmap.
• StackTrace and GovernAI — these are cloud-only. They are not part of self-hosted GetStackLens, and we are not planning Helm charts or in-cluster installs for them. If you need deep trace analytics, policy packs, or governance workflows built for regulated teams, that is the managed cloud product.
• ArgoCD ApplicationSets — on the roadmap after the stacklens-platform chart settles: sample ApplicationSet + values-in-Git flows so upgrades are reviewed and applied by Argo instead of ad-hoc helm upgrade. That would apply only to this self-hosted stack (Identity, FlowOps, Gateway, UI) — not to cloud-only products.
• Horizontal scaling validation — we've tested multiple replicas per service but haven't stress-tested session affinity and connection pooling behaviour at scale.

We'll document these as we close them.

How to Give Feedback

The simplest way: open an issue on getstacklens-ai/stacklens-helm. Include your cluster setup (managed vs. self-hosted, ingress controller, K8s version) and the values you used — that context is what makes a bug report actionable.

If something goes completely sideways and you want to talk it through directly, there's a waitlist form at getstacklens.ai — leave a note in the message field and we'll get back to you.

Install Now

helm install stacklens \
  oci://ghcr.io/getstacklens-ai/helm/stacklens-platform \
  --version 0.2.10 \
  --namespace stacklens --create-namespace \
  --set ingress.host=app.example.com \
  --set secrets.jwtSecret="$(openssl rand -base64 32)"

We're actively watching issues and feedback during this testing window. The more environments this gets installed into before we cut a stable release, the better the stable release will be.

If you try it — thank you. Tell us what you found.