Introduction
What Telark does, who it is for, and what it does not do.
Telark is a protection gate for your Kubernetes applications: you decide what can change an app, and when. It is a self-hosted control plane, installed with one Helm chart, that works at the level of applications instead of individual Kubernetes objects.
The problem
In a shared cluster, anyone with access can change a critical application at any time. RBAC is static: it cannot say "nobody touches checkout between 22:00 and 02:00 tonight". Change freezes run on a chat message, and one deletion, scale-down or image swap during a release becomes an outage. When something breaks, answering "what changed?" means reading events, rollout history and pod status across several workloads.
What you get
- Protect critical apps during risky windows. A protection plan blocks chosen changes (deletion, scaling, image changes, config and Secret edits, storage) for an application or namespace, for a time window. Start in audit mode, switch to enforce when you trust what it reports. A plan can require approval; plans in the Production environment always do. Kyverno, which ships with the chart, enforces plans at admission.
- Prove the protection is in force. Telark reads the live cluster back, reports drift and every violation, and produces a downloadable report (HTML, Markdown, JSON or CSV) when a plan ends.
- See every change and undo it. Every change to an application is recorded field by field, deletions included, with a snapshot you can roll back to from the dashboard.
- Understand incidents faster. Insights writes one card per affected workload with the likely cause, the evidence and the change it followed, and reviews each application's setup against 60 rules. By default, deterministic rules decide every finding and a small open-weight model running in your cluster only rewrites the wording; an opt-in deep mode lets the model investigate with the same read-only tools. It is read-only, needs no API key and works air-gapped.
- Control who can do what. Sign in with passkeys or Google, get roles scoped per area, and add per-action deny rules such as "may edit plans, may not approve them".
Underneath, Telark groups workloads into applications automatically, so you protect and inspect "checkout", not seventeen Deployments.
Who it is for
Platform and SRE teams running shared Kubernetes clusters for several application teams, and anyone who owns release windows, maintenance windows or production freezes.
What it is not
- Not multi-cluster. One installation covers one cluster.
- Not a hosted service. You run it; the license does not allow offering it as a managed service.
- Not auto-remediation. Insights suggests; it never changes your cluster. Only a rollback you trigger writes to your workloads.
Status
Early access. Every custom resource is v1alpha1 in the telark.io API group, and the chart and API may change before 1.0. Pin a chart version.