Try it on a local cluster

Tiphys reads your systems wherever they're hosted. To try it without a cloud account, connect a Kubernetes cluster on your own computer: kind, k3d, or the one built into Docker Desktop. Tiphys reaches it through the connector, a small Deployment that dials out to Tiphys over HTTPS. Nothing reaches into your computer, so you need no load balancer, ingress, public endpoint, or cloud identity.

This works the same on Apple Silicon (arm64) and Intel or AMD (amd64): the connector runs on the stock python:3.12-alpine image, which is published for both.

You need Docker, kubectl, the Tiphys Admin role in your company's Tiphys, and outbound HTTPS from the cluster to connect.tiphys.intelligant.ai (port 443).

1. Create a cluster

Pick one. kind and k3d also point kubectl at the new cluster.

kind

kind create cluster --name tiphys
kubectl config current-context    # kind-tiphys

k3d

k3d cluster create tiphys
kubectl config current-context    # k3d-tiphys

Docker Desktop

In Docker Desktop, open Settings, then Kubernetes, turn on Enable Kubernetes, and apply; the first start takes a few minutes. Then:

kubectl config use-context docker-desktop

Optionally, give Tiphys something to look at, such as one healthy Deployment and one that can't pull its image:

kubectl create namespace demo
kubectl -n demo create deployment web --image=nginx:1.27 --replicas=2
kubectl -n demo create deployment broken --image=nginx:no-such-tag

2. Connect it in Tiphys

In Tiphys, open Clusters and choose Connect a cluster (it's already open when no cluster is connected).
Under What runs it?, choose Kubernetes. Under How should Tiphys reach it?, choose Install the connector.
Name it: enter a Name in Tiphys, such as my-laptop. Leave Allow approved changes off to start read-only (you can turn it on later). Choose Next.
Install the connector in your cluster: choose Download the manifest, then apply it with kubectl pointed at the local cluster, from the folder you saved it in:
```
kubectl apply -f tiphys-connector.yaml
```
Connect: within a few seconds, Tiphys says Connected. Choose Done.

The manifest holds the connector's token, so keep it like a password. Each download issues a new token and the previous one stops working, so always apply the file you downloaded last.

To check the connector from your side:

kubectl -n tiphys-connector get pods
kubectl -n tiphys-connector logs deploy/tiphys-connector

A healthy connector logs connected. connection refused: download a new manifest from Tiphys means its token isn't the current one: choose Get the manifest again on the cluster's row and apply that file. The connector reconnects by itself after a network drop; to make it reconnect now, run kubectl -n tiphys-connector rollout restart deploy/tiphys-connector.

3. What read-only gives you

The connector's service account can get, list, and watch what Tiphys reads across the cluster, never Secrets, and it can't change anything: the connector refuses any change it's sent.

Chat about the cluster ("Why is the broken deployment in demo failing?"), scans, and health reports.
Tiphys checks the cluster on its own, as it does On-Prem: a scan and a health report as soon as its connector first connects, then a rescan and a fresh report every hour. A new critical finding shows as a badge on the cluster and a line on its Reports page.
Helm releases, read from the labels Helm puts on what it installs (without revision history or values, which Helm keeps in Secrets).
Changes are handed over as manifests and bundles to download and apply yourself.
Cloud services need a linked cloud account, so they're off for a local cluster. Everything else works without one.

4. Allow approved changes

To let Tiphys apply the changes someone approves:

On the cluster's row under Clusters, choose Allow approved changes.
Optionally, Limit to namespaces, such as demo; empty means all namespaces. Cluster-wide changes (CRDs, cluster roles, webhooks, new namespaces) are a separate checkbox and stay off unless you turn them on.
Choose Allow approved changes, then Download the manifest and apply it again:
```
kubectl apply -f tiphys-connector.yaml
```

The new manifest adds a tiphys-writer service account with the edit role in the namespaces you chose (or every namespace), and lets the connector act as that writer when Tiphys applies a change. Every change is dry-run first and waits for someone to approve it in Tiphys, and Tiphys's protected namespaces stay off-limits. Helm chart installs aren't applied through a connector: Tiphys hands over the helm commands and values as a bundle to run yourself.

To stop, choose Stop approved changes and apply the manifest you download then. The connector refuses changes again right away. If cluster-wide changes were on, also run the kubectl delete clusterrolebinding command Tiphys shows.

5. Remove it

In Tiphys, on the cluster's row under Clusters, choose Disconnect, then confirm. Its token stops working, and the cluster no longer counts toward your plan's clusters.

Delete the local cluster:

kind delete cluster --name tiphys     # kind
k3d cluster delete tiphys             # k3d

For Docker Desktop, reset or turn off Kubernetes in its settings, or keep the cluster and remove only the connector and its access:

kubectl delete namespace tiphys-connector
kubectl delete clusterrole,clusterrolebinding,rolebinding -A \
  -l app.kubernetes.io/name=tiphys-connector