A protection gate for your Kubernetes applications
Decide what can change an application, and when. Self-hosted, in your cluster.
- One Helm chart
- Kubernetes 1.30+
- Elastic License 2.0
The freeze you announced in chat was a request, not a rule.
It is 23:40, the release is half out, and someone scales checkout to zero from a terminal they forgot was pointed at production. Kubernetes allowed it, because RBAC decides who may change a workload, never when.
Today: A change freeze is a message in a chat channel.
With Telark: A protection plan blocks the changes you name, for exactly the window you set.
Today: You hope nobody edited or removed the safeguards.
With Telark: Telark reads the live cluster and flags drift.
Today: “What changed?” costs an hour of kubectl.
With Telark: Every change is recorded field by field, with a snapshot you can roll back to.
Today: You piece the incident together from six workloads.
With Telark: Insights names the affected workload and the likely cause.
Today: Access is all or nothing per namespace.
With Telark: Roles per area with per-action rules.
Discover. Plan. Enforce. Verify.
You work in a dashboard, not in policy YAML.
Discover
Telark groups your workloads into applications on its own. You protect checkout, not seventeen Deployments.
Plan
Pick the changes to block from ready-made templates, choose the app or namespace and the window, and run it in audit mode first.
Enforce
While the window is open, Kyverno (bundled with the chart by default, or one you already run) refuses those changes at admission.
Verify
Telark checks the live cluster for the policies it expects and reports what was blocked, audited or tampered with.
Freeze the apps that matter, and prove the freeze held.
A plan arms itself when the window opens and disarms itself when it closes. While it runs, Telark checks the cluster instead of trusting that a write succeeded.
Lock chosen changes for a set time window.
A plan covers an application or namespace, for a release, a maintenance window or an audit. Kyverno enforces it at admission.
- Nine ready-made templates cover deletion, scaling, image changes, ConfigMap and Secret edits, storage and more.
- Start in audit mode to see what the plan would block, then switch to enforce.
- Require an approval before a plan deploys. Production plans always ask, and nobody approves their own request.
- Exclude kinds or single resources that must stay changeable, without splitting the plan.
2h 14m left
- Scope
- 3 applications
- Mode
- enforce
- Templates
- 4 active
- Health
- Healthy
- ci-deployer delete deployment/checkout-api
- alex@ scale replicas 3 → 0
Checked against the live cluster, not assumed.
While a plan is active, Telark checks that each policy it expects is present, ready and in the right mode, and puts back anything removed or edited.
- Health reads Healthy, Drifted, Degraded or Unknown, straight from cluster state.
- Every change the plan blocked or audited shows up as a violation, newest first.
- When a plan ends, Telark keeps a report of its scope, timeline, health and every violation.
plan health · plan_8a3f12
4 declared policies · cluster reconciled 12s ago
- Healthy
checkout-block-delete-enforce
ns: checkout · action: Enforce · ready
- Healthy
checkout-block-image-types-enforce
ns: checkout · action: Enforce · ready
- Healthy
checkout-block-storage-changes-enforce
ns: checkout · action: Enforce · ready
- Healthy
payments-block-delete-enforce
ns: payments · action: Enforce · ready
- Degraded
payments-block-replica-scaling-enforce
ns: payments · action: Enforce · not ready
- Drifted
checkout-block-config-secret-resource-changes-enforce
ns: checkout · action: — · not ready
See every change that reached an app, and undo it.
Telark records every change to an application field by field, deletions included, and keeps a snapshot of what it looked like before. “What changed?” becomes one page, not an hour in events and rollout history.
- Changes are grouped by application and classified by kind.
- Roll back to an earlier snapshot from the dashboard.
- Older snapshots are pruned automatically.
checkout · Change history
- Roll back
14:02 · resources
checkout-api · limits.memory: 512Mi → 256Mi
- Roll back
11:40 · deployment
checkout-api · image: api:1.8.2 → api:1.9.0
- Roll back
09:15 · scaling
checkout-worker · replicas: 3 → 5
- Roll back
08:30 · config
checkout-api · configmap/checkout-config: rev 41 → rev 42
- Roll back
Yesterday 22:10 · deployment
checkout-worker · image: worker:2.3.0 → worker:2.3.1
- Roll back
Yesterday 16:45 · scaling
checkout-api · replicas: 2 → 3
Understand an incident without digging.
When an app degrades, Insights reads its events, pod status and recent changes, and writes one card per affected workload: the likely cause, the evidence it used and the change it followed. A card resolves itself when the workload recovers.
Out of memory: containers are OOMKilled and restarting.
- Last state OOMKilled, exit code 137
- 6 restarts in 10 minutes
- BackOff events on 2 of 3 pods
14:02 · limits.memory 512Mi → 256Mi
Rules decide · local model rewords · read-only
How it stays trustworthy
Rules decide
By default, deterministic rules decide every finding. A small open-weight model, served in your cluster by Ollama, only rewrites the wording.
Unfaithful rewrites are discarded
Telark discards any rewrite that drops or invents a fact.
Deep mode is opt-in
For bigger nodes or a GPU, deep mode lets the model investigate with the same read-only tools.
Read-only, in your cluster
It never changes your cluster. No data leaves it, no API key is needed, and it works air-gapped.
On by default and optional. The rest of Telark keeps working without it.
One Helm chart. Your cluster, your data.
The CRDs, the services, the dashboard and, by default, Kyverno install together, inside your cluster, with no external service. Your applications appear on their own.
helm install telark oci://ghcr.io/telark/charts/telark -n telark --create-namespace \
--set app.auth.bootstrap.admin=test@example.comYou need Kubernetes 1.30+, Helm 3 and a default StorageClass, which managed clusters and kind, minikube or k3d already have. The command installs the standard mode, sized for up to about 1,000 applications. Pick your mode in the install guide before you run it: Choose a size. Already run Kyverno? Turn off the bundled one with a single Helm value and Telark uses yours.
Your data stays put
- Single cluster. No phone-home, no telemetry.
- Insights runs on an in-cluster model, so analysis data stays in the cluster.
- Source-available under the Elastic License 2.0: read it, modify it, self-host it.
Access control
- Sign in with a passkey or with Google SSO.
- Roles grant a level per area, from read-only to admin.
- Deny rules remove single actions and win over any level.
Early access: the API is telark.io/v1alpha1 and may change before 1.0. Pin a chart version. Known limitations: single cluster per install. By default the chart bundles Kyverno, Redis, NATS, metrics-server and Ollama, and the bundled Kyverno can be turned off to use one you already run.
Make your next freeze a rule, not a request.
Install with one Helm command, find your applications already listed, and create a protection plan in audit mode.