Capabilities

Tiphys has three modules. Each one is a Helm toggle (modules.core, modules.cloud, modules.corePlus), and each has its own requirements. This page describes the latest release. For plans and pricing, see the Intelligant AI pricing page.

Module	Crew	What it adds	Needs
Cluster	Lynceus	Read-only Kubernetes observability, knowledge graph, scheduled health reports, in-cluster chat UI	Any Kubernetes 1.29+ cluster. Always on.
Cloud	Aeolus	A read-only view of the cloud account behind your cluster: identity, managed databases, storage, registries, secrets, networking, cost	A cluster running in a supported cloud, and a cloud role for Tiphys
IDP	Argus	Golden-path scaffolding, manifest generation, approval-gated writes, audit log	A path for changes to reach your clusters

The modules are independent: turning Cloud off doesn't block IDP, and vice versa. A few tools span two modules (scaffolding a service's manifests together with its cloud role, for example) and need both.

Cluster (Lynceus)

Helm key: modules.core. Always on. Runs on any Kubernetes 1.29+ cluster — managed or self-hosted, in a cloud or on-prem. It needs only the service account and RBAC the chart creates; no cloud identity.

What operators use it for: troubleshooting ("why is this pod crashlooping?"), health dashboards, convention detection, policy drift, routing issues. The agent reads cluster state, infers patterns, and explains what's wrong without proposing any change that needs approval.

Capabilities at a glance:

Live Kubernetes reads — pod state, events, logs, rollouts, network policy, ingress, service endpoints, HPA / PDB status.
Helm release inspection — list deployed charts and read their effective values via the Kubernetes API. No helm binary on the pod.
Prometheus integration — auto-discovers an in-cluster Prometheus service; runs queries, surfaces alerts, exposes a curated set of presets.
Knowledge graph — startup scan that catalogs namespaces, workloads, CRDs, conventions, and detected integrations (Argo CD, Kyverno, external-secrets). Persisted across pod restarts; refreshed hourly.
Scheduled health reports — background rule set produces prioritized findings every 30 minutes by default; snooze any finding with a TTL.

Cloud (Aeolus)

Helm key: modules.cloud. A read-only view of the cloud account your cluster runs in, plus scaffolding for the cloud side of new services.

Cloud only works when your cluster runs in a cloud. On-prem clusters, and clusters without a cloud account behind them, run Cluster and IDP without it; the agent tells you what it can't see rather than failing silently.

Requirements by cloud provider

Tiphys detects the provider from your nodes; you can also set it with modules.cloud.provider (aws, azure, or gcp).

Provider	Cloud module	Identity for the Tiphys service account	Permissions
AWS	Available	IRSA (register the cluster's OIDC provider in IAM) or EKS Pod Identity (install the Pod Identity Agent add-on)	The read-only Cloud policy from IAM setup
Google Cloud	Not yet — on the roadmap	—	—
Azure	Not yet — on the roadmap	—	—
On-prem / no cloud	Not applicable	—	—

If Amazon Bedrock is your model provider, the same AWS role also carries bedrock:InvokeModel — that's the one case where an install without Cloud still needs AWS identity. With any OpenAI-compatible endpoint, Cluster and IDP need no cloud identity at all. See Getting started.

What it reads on AWS (all read-only):

IAM — roles, attached policies, IRSA and Pod Identity trust-policy verification.
RDS + ElastiCache — managed-database inventory.
S3 — bucket listing + metadata. Never reads object content.
ECR — repository inventory.
Secrets Manager — names + ARNs only. Never reads secret values.
EC2 networking — VPCs, subnets, security groups.
Cost Explorer — per-service cost summary.

Scaffolding output: Terraform for a workload's IAM role and trust policy, and ExternalSecret manifests. Paired with IDP, a new service's manifests, role, and ExternalSecret come out as one change set.

What operators use it for: "Which IAM role does this workload assume?" / "Does this ServiceAccount's trust policy actually accept the right federated identity?" / "What's driving this month's spend?"

IDP (Argus)

Helm key: modules.corePlus. Golden-path scaffolding, manifest generation, and approval-gated writes. Helps teams ship new services into the cluster without waiting on the platform team.

IDP needs a path for changes to reach your clusters. That can be Argo CD or a deploy pipeline that ships from your repositories, or Tiphys's own approval-gated writes (modules.corePlus.writeOperations.enabled). Without one of those, Argus can still scaffold and generate manifests, but nothing it produces gets deployed.

Write surface (all gated, dry-run-first, never target protected namespaces):

Apply, scale, restart-rollout, and cordon operations on Kubernetes workloads.
Helm install and upgrade against the curated public chart catalog or any registry registered via helm.repos[] in your values.
Golden paths — render and apply a pre-approved workload template.

Safety invariants (hard-coded; no Helm value overrides them):

No writes to kube-system, kube-public, kube-node-lease, or tiphys.
No cluster-wide admin, no Secret value reads.
Every write dry-runs first; real apply only after explicit operator approval in the UI.
Every approved action is audit-logged with operator id, approval id, and payload hash.

See Write operations for the approval flow.

Enabling or disabling modules

Each module toggles via Helm values:

modules:
  cloud:
    enabled: true
    provider: aws
  corePlus:           # IDP (Argus)
    enabled: true
    writeOperations:
      enabled: true   # off = scaffolding only

The chart validates these keys against its schema, so a misspelled or outdated key fails the install instead of being ignored.

Apply the change with helm upgrade. Existing data (reports, approvals, audit log) survives — nothing in the backing stores is gated on which module created it.

The chart and images are published to GitHub Container Registry; see Getting started for the install command.

Status in the UI

The dashboard shows each module as Active (enabled and ready) or Inactive (disabled in Helm values). If modules.cloud.provider doesn't match the cloud Tiphys detects from your nodes, it logs a warning that cloud results may be inaccurate.

The agent's system prompt carries the same module state on every conversation turn, so it can answer "can I do X?" precisely without a tool call.