A protection gate for your Kubernetes workloads.
Anyone with cluster access can change anything, at any time. telark puts a time-bounded gate in front of the workloads that matter — decided at admission, verified against live cluster state.
2h 14m left
- Scope
- 3 applications
- Mode
- enforce
- Templates
- 4 active
- Health
- Healthy
- ci-deployer delete deployment/checkout-api
- alex@ scale replicas 3 → 0
Decide what can change your applications — and when.
telark groups your workloads into applications, binds ready-made policy templates to a scope and a window, enforces the decision at admission, and verifies the result against live cluster state.
- Discover
- Plan
- Enforce
- Verify
Protection windows that arm and disarm themselves.
Bind ready-made policy templates to a scope and a time range. The plan enforces only between startAt and endAt — audit first, enforce when you trust it.
Learn moreApplication-aware, not namespace-blind.
telark groups raw workloads into applications automatically. Protect “checkout”, not seventeen Deployments — the plan resolves that boundary on activation.
Learn moreVerified against the cluster, not the API.
telark reads live cluster state to confirm the protection you asked for is the protection actually running. Drift, missing policies, tampering — all surfaced.
Learn moreLock down the workloads. For exactly as long as you need.
A protection plan binds policy templates to a scope and a time range. Pick what the window forbids, set audit or enforce, and either run it now or schedule it. The in-cluster controller moves the plan through scheduled → active → terminated; while active, telark deploys admission policies labelled by plan ID so the cleanup is exact.
- Nine ready-made templates cover the changes that actually hurt — no policy language to write.
- Start in audit mode to see what would have been blocked, flip to enforce when you trust it.
- Windows are first-class — set startAt and endAt; the plan arms and disarms itself on a ~30-second controller tick.
- Cancel, reactivate, duplicate, and a transactional prepare for dry-running scope conflicts before anything is applied.
Pick what a window forbids — deletes, scaling, image sources, storage, config and secret edits. Parameterised where it matters, with no policy language to learn.
- Block deletion
- Block replica scaling
- Block image tags
- Block storage changes
- +5 more
Browse the full catalogue in the dashboard
Protect “checkout”. Not seventeen Deployments.
telark groups raw workloads into applications automatically and keeps that grouping current as the cluster changes. When a plan activates, its resolver turns the application ID into the live list of workloads — Deployments, StatefulSets, DaemonSets — and the policy applier writes admission rules that target exactly that set.
- Scope choice is per-plan: applications or namespaces, depending on what each template supports.
- Discovery runs multi-replica with leader election; followers pick up force-sync markers.
- Namespace exclusion is honoured at the listing layer — excluded namespaces never enter any plan's scope.
- Plan resolution is deterministic — re-running it on the same cluster state produces the same workload set.
- Mon 09:00Draft
Plan created (draft)
- Mon 17:30Scheduled
Schedule confirmed (scheduled)
- Mon 20:00Active
Window opens — policies deployed
- Tue 02:14Drift
Drift detected — config edited outside plan
- Tue 06:00Terminated
Window closes — policies removed
Cluster truth. Not the API's word for it.
Health is computed by reading the cluster, not by trusting that the write succeeded. telark lists the admission policies labelled by plan ID, checks each declared policy is present, ready, and configured with the failure action your plan demands, and watches for stray labelled policies the plan never declared.
- Healthy — every declared policy present, ready, and matching the plan's mode.
- Drifted — a declared policy missing, an unexpected labelled policy present, or the failure action tampered with.
- Degraded — a policy is present but the engine has not reconciled it yet.
- Unknown — plan not yet active. No false confidence.
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
- Degraded
payments-block-replica-scaling-enforce
ns: payments · action: Enforce · not ready
- Drift
checkout-block-config-secret-resource-changes-enforce
ns: checkout · action: — · not ready
One command. Lives in your cluster.
Install into the cluster you already own — CRDs, services, and the dashboard ship in a single Helm chart. Discovery starts immediately; the first protection window is minutes away.
helm install telark oci://ghcr.io/telark/charts/telark -n telark --create-namespaceCRDs ship as a bundled subchart — no separate step. Size the whole install with --set app.mode=minimal | standard | performance.
- 01
Install once
One Helm release brings the CRDs, services, and dashboard. Kubernetes 1.30 or newer, GA APIs only.
- 02
Open the dashboard
Enabled by default. Port-forward it, or turn on the optional Ingress for a real hostname and TLS. Sign in with a passkey or Google SSO.
kubectl port-forward -n telark svc/telark-ui-service 3000:8080 - 03
Discover, then protect
Workloads group into applications in real time. Pick templates, a scope, audit or enforce, and a window — the controller does the rest.
Your cluster. Your data. Your compliance posture.
telark runs entirely inside your Kubernetes cluster. No data leaves it. Source-available under the Elastic License 2.0 — read the source, modify it, self-host it. The one thing the license does not allow is offering telark to others as a managed service.
- Single-cluster, single-tenant. No phone-home, no telemetry.
- AI insights are optional, per-application, and off until you configure a provider.
- Optional Prometheus ServiceMonitor and HPA autoscaling — autoscaling turns on automatically in performance mode.
Free, forever. Self-hosted.
All features included. Run it in your cluster, on your terms.
telark for teams.
We're shaping the next tier. Get on the list and we'll tell you the moment it lands.
Open your first protection window.
One Helm command. Discovery picks up your applications. Pick a template, pick a window. The cluster does the rest.