Quickstart

One Helm release installs everything: the services, the custom resource definitions, the bundled policy engine, and the dashboard. There is no separate CRD step and no bootstrap chart.

Prerequisites

Requirement	Detail
Kubernetes	1.30 or newer — enforced by the chart's `kubeVersion`. 1.33+ is the tested tier.
Helm	3.x.
Cluster access	cluster-admin for the install — telark registers CRDs, ClusterRoles, and an admission webhook.
Storage	A default StorageClass. The exporter mounts a PersistentVolumeClaim for snapshots.

1. Install

helm install telark oci://ghcr.io/telark/charts/telark -n telark --create-namespace

That is the whole install. The CRDs ship as a bundled subchart and are kept on uninstall (helm.sh/resource-policy: keep). If something else already manages them — GitOps applying CRDs ahead of the release, say — add --set crds.enabled=false.

Pick a size

app.mode sizes every telark service from one flag — replicas, resource requests, client rate limits, and disruption budgets. The default is standard.

helm install telark oci://ghcr.io/telark/charts/telark -n telark --create-namespace \
  --set app.mode=performance

Mode	For
`minimal`	Dev, demos, evaluation — single replica, no disruption budgets.
`standard` (default)	Small-to-mid production — 2 replicas, disruption budgets.
`performance`	Large clusters — 3 replicas, autoscaling on. Needs a ReadWriteMany storage class for the exporter (`--set app.persistence.storageClass=<rwx-class>`).

Name your first admin

Emails listed in app.auth.bootstrap.admins receive the Admin role on first login. The default is contact@telark.io, so set your own before you install:

helm install telark oci://ghcr.io/telark/charts/telark -n telark --create-namespace \
  --set app.auth.bootstrap.admins[0]=you@corp.com

Helm does not remember --set flags across upgrades — re-pass them on every helm upgrade.

2. Verify

kubectl get pods -n telark -l app.kubernetes.io/instance=telark
helm test telark -n telark

helm test runs a readiness probe against the auth service.

3. Open the dashboard

The dashboard ships enabled by default and is served on port 8080. Port-forward it — no ingress required:

kubectl port-forward -n telark svc/telark-ui-service 3000:8080

Open http://localhost:3000.

For a real hostname and TLS, turn on the optional Ingress instead — see Guides → Installing.

telark is passkey-first. Register a passkey on the sign-in screen, or use Google OIDC if you have wired it up (Guides → Configuring Google OIDC). The first login from a bootstrap admin email lands with the Admin role; everyone else starts with no scopes until an admin grants them.

5. Create your first protection plan

Discovery starts grouping workloads into applications as soon as the pods are up. Once an application you recognise appears:

Open Protection plans → New plan.
Pick a scope — one or more discovered applications, or one or more namespaces.
Add policy templates. Start with block-delete; add block-replica-scaling if the scope is applications.
Choose a mode. Leave it on audit for the first run — violations are recorded but nothing is blocked.
Choose a time mode — permanent, or time_range with a startAt / endAt window that arms and disarms itself.
Save, then run it now or leave it scheduled.

While the plan is active, telark reads the cluster back to confirm the protection you asked for is the protection actually running. When you trust what audit reports, flip the plan to enforce.

On this page