Infrastructure
This page covers the platform’s architecture and the infrastructure controls behind both deployment models. For how those controls map to the guarantees you get (isolation, access, and credential handling), see the Security model.
Architecture
Introspection is Kubernetes-native and deployed by GitOps: every environment is declared in git and continuously reconciled onto the cluster with Argo CD and Helm, so what runs always matches what’s in version control. A dedicated deployment is the same stack, provisioned as its own isolated environment.
The platform is built on a small, well-understood set of components:
| Component | What it does |
|---|---|
| PostgreSQL | Primary store for configuration and control-plane data |
| ClickHouse | Columnar store for conversations, events, and analytics at scale |
| Valkey | In-memory cache and realtime fan-out |
| Restate | Durable execution for long-running, reliable workflows |
| Envoy Gateway | The edge that authenticates and routes API traffic |
| Zitadel | Identity provider for every principal the platform authenticates: operators, applications and service accounts, and brokered end users |
Encryption
In transit
All traffic uses TLS 1.2 or higher: clients and SDKs to the platform, communication between internal services, and connections to databases and caches.
At rest
All stored data is encrypted at rest: databases (PostgreSQL, ClickHouse), caches (Valkey), object storage (S3 / GCS / Azure Blob), and Kubernetes secrets and volumes.
Managed deployments use provider-managed keys. Enterprise and dedicated deployments can use customer-managed keys (CMEK) through the deployment’s cloud key management service. See Data Handling.
Field-level encryption
Sensitive fields (API keys, tokens, credentials) use application-level encryption scoped to your organization. Plaintext is never written to disk.
Networking
- No public endpoints. Databases, caches, and internal services are reachable only through private networking.
- Egress control. Sandboxed workloads use domain whitelisting and egress restrictions.
- Consistent posture across clouds. Deployments follow the same security posture wherever they run.
Identity and access
Services authenticate using cloud-native workload identity, with no exported service account keys (IRSA on AWS, Workload Identity Federation on GCP, Managed Identity on Azure).
All access follows least-privilege principles: no broad roles are used, and each workload gets scoped permissions for only the resources it needs.
The dashboard authenticates through OIDC. Server-side SDK callers use environment-scoped runtime API keys or service-account tokens; the CLI uses a member-bound browser login with server-controlled scopes. See the Security model for the full design.
Workload hardening
All workloads run with hardened security contexts: non-root execution, read-only root filesystem, no privilege escalation, dropped Linux capabilities, and enforced CPU and memory limits.
Sandbox isolation
Agent workloads run in ephemeral environments with scoped access to only the resources they need, egress domain whitelisting, automatic cleanup after execution, and no persistent state between runs.
API key handling
API keys are hashed before storage. The full key is shown only once, on creation, and is never transmitted between services in the clear.