Telark
Features

Protect. Prove. Recover. Understand. Control access.

Protect critical apps during risky windows, prove the protection held, see and undo every change, understand incidents faster, and decide who may do what.

01 · Protect

Lock chosen changes to an app, for a set time window.

A freeze announced in chat is a request. A protection plan binds policy templates to a scope (applications or namespaces), a mode (audit or enforce) and a schedule, and Kyverno enforces it at admission.

  • Audit mode records what would be blocked, enforce mode blocks it. Switching modes updates the deployed policies in place.
  • Exclusions narrow a plan without splitting it.
  1. Mon 09:00

    Plan created, approval requested

    Pending approval
  2. Mon 17:30

    Approved, waiting for the window

    Scheduled
  3. Mon 20:00

    Window opens, policies deployed

    Active
  4. Tue 02:14

    Drift found: policy edited outside the plan

    Drift
  5. Tue 02:15

    Drift repaired, policy redeployed

    Active
  6. Tue 06:00

    Window closes, policies removed, report kept

    Terminated

Nine ready-made templates. No policy language to write.

Each template blocks one kind of change and asks only for the parameters it needs.

  • Creating any resourcePrevents creation of any resource within the scope.block-create
  • Updating any resourcePrevents updates to any resource within the scope.block-update
  • Deleting any resourcePrevents deletion of any resource within the scope.block-delete
  • Images matching blocked patternsRejects container images matching the patterns you set.block-image-types
  • Images with blocked tagsRejects the image tags you list, such as latest.block-image-tags
  • Changing replica countsApplications onlyPins Deployment and StatefulSet replica counts.block-replica-scaling
  • Creating, deleting or editing storageLocks PersistentVolumeClaims and volume definitions.block-storage-changes
  • Updating or deleting ConfigMaps & SecretsRejects updates and deletes on ConfigMaps and Secrets.block-config-secret-resource-changes
  • Changing config mounts & env sourcesFreezes volume mounts and env-source references.block-workload-config-mount-changes

  • Protection that arms and disarms itself

    A plan runs for a time range, in weekly repeating windows, or until you cancel it. Telark deploys its policies when a window opens and removes them when it closes.

    • Cancel and reactivate by hand when you mean now, without waiting for the window edge.
    • Duplicate a plan to reuse its configuration, with its own approval if it needs one.

  • Nothing deploys until someone else says yes

    Approval is automatic or required. A plan that requires it deploys nothing until an approver approves or rejects it with a comment.

    • Plans in the Production environment always require approval.
    • The requester can never decide their own plan. Once approved, scope, policies, schedule and mode are locked.
    • Kinds, environments and tags ship built in. Add your own.

  • Protect “checkout”, not seventeen Deployments

    Telark groups your workloads into applications on its own and keeps the grouping current. A plan resolves each application to its namespaces and workloads when it activates.

    • Scope a plan to applications or to namespaces, depending on what each template supports.
    • Namespaces you exclude never enter any plan's scope.
    • Each application shows the protection plans that cover it now and the ones about to.
02 · Prove

Checked against the live cluster, not assumed.

A successful write is not proof. Telark reads the Kyverno policies that actually exist and compares them with what each plan declares.

  • Health reads Healthy, Drifted, Degraded or Unknown, straight from cluster state.
  • Drift is repaired: missing or edited policies are redeployed, a changed mode is put back and stray labeled policies removed.

plan health · plan_8a3f12

4 declared policies · cluster reconciled 12s ago

Drifted

  • 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

    Healthy

  • payments-block-replica-scaling-enforce

    ns: payments · action: Enforce · not ready

    Degraded

  • checkout-block-config-secret-resource-changes-enforce

    ns: checkout · action: — · not ready

    Drifted

  • Every change the plan caught, newest first

    Admission decisions come from Kyverno's policy-violation events, filtered to the policies the plan deployed. Blocked creates, updates and deletes all appear.

    • Each decision carries the resource, the result, Kyverno's message and the user who sent the request.
    • The plan's page lists every decision since the plan started, and its reports keep the record.

  • A record of every window after it closes

    A report records the plan's scope, policies, timeline, health and every admission decision, when the plan or one of its windows ends, or on demand.

    • Download each report as HTML, Markdown, JSON or CSV.
03 · Recover

See every change that reached an app, and undo it.

When an incident starts with “what changed?”, the answer should be one page. On every material change, Telark records it field by field, deletions included, and snapshots the application's objects from before the change.

  • Each change is classified by kind.
  • Roll back to a snapshot from the dashboard. A rollback is itself recorded, so it can be rolled back too.
  • Snapshot retention is configurable, and older snapshots are pruned.
04 · Understand

Understand an incident without digging.

When an application 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.

  • Causes include crash loops, out of memory, image pull failures, scheduling, failing probes, stuck rollouts and regressions right after a config change.
  • By default, deterministic rules decide every finding and a small open-weight model served in your cluster by Ollama only rewrites the wording. Telark discards any rewrite that drops or invents a fact.
  • An opt-in deep mode lets the model investigate with the same read-only tools.
  • Read-only: Insights never changes your cluster. No data leaves it, no API key is needed, and it works air-gapped.

Insights reads what the core loop already knows

Plans, history and Insights all work on the same applications. Insights reads them and never writes back.

  • Applications
  • Change history
  • Protection plans

Insights· read-only

  • A setup review against 60 rules

    Insights reviews each application's setup and lists what to fix, such as a single replica with no disruption budget in production.

  • Decision support, not autopilot

    Check a card before you act on it. Insights suggests, you decide.

    • On by default. Switch it off in Settings, and the rest of Telark keeps working.
    • Setup reviews run on their own. Incident analysis runs on demand or automatically.
05 · Control access

Decide who may do what, per area.

Access that is all or nothing per namespace is too coarse for release work. People sign in with a passkey or Google SSO, and roles from the user and the user's groups grant a level per area, from read-only to admin.

  • Deny rules remove single actions and win over any level.
  • Every protection plan action has its own deny rule, so a role can edit plans but not approve them.
  • You cannot grant a role above your own level or edit your own roles.
  • Users, groups and roles are Kubernetes custom resources in the telark.io API group.

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.

Get startedRead the docs