# Deployment & infrastructure

Choose where the Introspection platform runs — Managed Cloud, BYOC, or on-prem — and understand the stack and controls that are the same in every model.

Every deployment model places the same platform in a different operating
boundary. The split between the Control Plane (configuration and identity) and
the Data Plane (tasks and agent-run data) is what the models move around — see
[Control Plane and Data Plane](/platform#control-plane-and-data-plane) for that
boundary. The deployment model decides where those components — and especially
the customer-data boundary — operate.

The organization view shows each data plane's cloud, region, isolation model, and health.

## The three models

### Managed Cloud

Introspection operates the platform in Introspection-managed cloud
infrastructure. This is the fastest path to production and requires no customer
cloud account or cluster operations. Organization and project boundaries keep
customer data isolated within the managed service.

### BYOC

Introspection deploys the Data Plane into your AWS, GCP, or Azure account. You
choose the supported cloud and region, and the agent-run data stays inside that
cloud boundary. Network controls and topology are coordinated as part of the
deployment. The Control Plane and SDK contract remain consistent with Managed
Cloud.

BYOC provisioning is available to eligible Max and Enterprise organizations
when enabled for the account. Contact Introspection to confirm availability
and the supported cloud and region for your deployment.

### On-prem

The platform runs in infrastructure you operate, including on-premises or
air-gapped environments. This is the deployment model for requirements that
cannot use a public-cloud control or data boundary. Exact topology, identity,
upgrades, and support responsibilities are defined as part of the Enterprise
deployment.

## Comparison

| | Managed Cloud | BYOC | On-prem |
| --- | --- | --- | --- |
| **Infrastructure location** | Introspection cloud account | Your AWS, GCP, or Azure account | Your datacenter or private environment |
| **Network boundary** | Introspection-managed | Your VPC and network controls | Your private or air-gapped network |
| **Operations** | Introspection-operated | Introspection-managed deployment in your account | Defined with the Enterprise deployment |
| **Best fit** | Fastest managed path | Cloud residency and customer-controlled networking | On-premises or air-gapped requirements |

Choosing between them:

- **Choose Managed Cloud** when you want Introspection to operate the infrastructure for you.
- **Choose BYOC** when data and network controls must stay in your cloud account.
- **Choose on-prem** when the platform must run in your private or air-gapped environment.

Deployment is an infrastructure decision, not a per-task runtime option. Projects
are assigned to the Data Plane deployments available to their organization;
changing that topology is an operational action, not an SDK parameter.

## The stack

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. Managed Cloud, BYOC, and on-prem place the same platform stack in different operating boundaries.

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** | OIDC identity provider for dashboard access and Introspection-hosted or brokered member login |

## Encryption

### In transit

External traffic between clients, SDKs, and Introspection is protected with
TLS. Managed Cloud ingress accepts TLS 1.2 or higher. Internal services,
databases, and caches remain on private cluster or cloud networks. Transport
protection inside that boundary depends on the service and deployment
configuration; some in-cluster connections use private HTTP rather than TLS.

### 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 Cloud uses provider-managed keys. BYOC and on-prem deployments can use customer-managed keys (CMEK) through the target environment's key-management service. See [Data handling](/support/data-handling#customer-managed-encryption-keys).

### Who owns which layer

| Layer | Owner |
| --- | --- |
| In transit (TLS) | Infrastructure — [above](#in-transit) |
| At rest (databases, caches, object storage, CMEK) | Infrastructure — [above](#at-rest) |
| Field-level encryption of decryptable secrets | Application — [Security model](/platform/security#encryption) |
| One-way API-key hashing | Application — [Security model](/platform/security#api-key-handling) |

## Networking

- **Private managed services.** Introspection-managed databases, caches, and
  internal services use private networking. Customer-supplied dependencies
  follow the networking configured for that deployment.
- **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](/platform/security) for the full design.

## Workload hardening

Application and sandbox workloads run with hardened security contexts,
including non-root execution, restricted privilege, and CPU and memory limits.
Cluster-level installers and other infrastructure components may require
controlled host access to provide the sandbox runtime.

Sandbox isolation — one ephemeral sandbox per task, scoped access, egress
whitelisting, automatic cleanup — and API-key handling are application
guarantees, specified in the [Security model](/platform/security) and
[Sandboxes](/platform/tasks-and-runs#sandboxes).

## Related

- [**Security model**](/platform/security): isolation, encryption, and credential handling across the deployment boundary.
- [**Data handling**](/support/data-handling): what agent-run data is held, residency, retention, and CMEK.
- [**Organizations & projects**](/platform/projects): the tenancy model deployments sit beneath.

Deployment & infrastructure

Choose where the Introspection platform runs — Managed Cloud, BYOC, or on-prem — and understand the stack and controls that are the same in every model.

Every deployment model places the same platform in a different operating boundary. The split between the Control Plane (configuration and identity) and the Data Plane (tasks and agent-run data) is what the models move around — see Control Plane and Data Plane for that boundary. The deployment model decides where those components — and especially the customer-data boundary — operate.

Organization data planes across AWS, Azure, and GCP with shared or dedicated isolation and healthy status — The organization view shows each data plane’s cloud, region, isolation model, and health.

The three models

Managed Cloud

Introspection operates the platform in Introspection-managed cloud infrastructure. This is the fastest path to production and requires no customer cloud account or cluster operations. Organization and project boundaries keep customer data isolated within the managed service.

BYOC

Introspection deploys the Data Plane into your AWS, GCP, or Azure account. You choose the supported cloud and region, and the agent-run data stays inside that cloud boundary. Network controls and topology are coordinated as part of the deployment. The Control Plane and SDK contract remain consistent with Managed Cloud.

BYOC provisioning is available to eligible Max and Enterprise organizations when enabled for the account. Contact Introspection to confirm availability and the supported cloud and region for your deployment.

On-prem

The platform runs in infrastructure you operate, including on-premises or air-gapped environments. This is the deployment model for requirements that cannot use a public-cloud control or data boundary. Exact topology, identity, upgrades, and support responsibilities are defined as part of the Enterprise deployment.

Comparison

	Managed Cloud	BYOC	On-prem
Infrastructure location	Introspection cloud account	Your AWS, GCP, or Azure account	Your datacenter or private environment
Network boundary	Introspection-managed	Your VPC and network controls	Your private or air-gapped network
Operations	Introspection-operated	Introspection-managed deployment in your account	Defined with the Enterprise deployment
Best fit	Fastest managed path	Cloud residency and customer-controlled networking	On-premises or air-gapped requirements

Choosing between them:

Choose Managed Cloud when you want Introspection to operate the infrastructure for you.
Choose BYOC when data and network controls must stay in your cloud account.
Choose on-prem when the platform must run in your private or air-gapped environment.

Deployment is an infrastructure decision, not a per-task runtime option. Projects are assigned to the Data Plane deployments available to their organization; changing that topology is an operational action, not an SDK parameter.

The stack

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. Managed Cloud, BYOC, and on-prem place the same platform stack in different operating boundaries.

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	OIDC identity provider for dashboard access and Introspection-hosted or brokered member login

Encryption

In transit

External traffic between clients, SDKs, and Introspection is protected with TLS. Managed Cloud ingress accepts TLS 1.2 or higher. Internal services, databases, and caches remain on private cluster or cloud networks. Transport protection inside that boundary depends on the service and deployment configuration; some in-cluster connections use private HTTP rather than TLS.

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 Cloud uses provider-managed keys. BYOC and on-prem deployments can use customer-managed keys (CMEK) through the target environment’s key-management service. See Data handling.

Who owns which layer

Layer	Owner
In transit (TLS)	Infrastructure — above
At rest (databases, caches, object storage, CMEK)	Infrastructure — above
Field-level encryption of decryptable secrets	Application — Security model
One-way API-key hashing	Application — Security model

Networking

Private managed services. Introspection-managed databases, caches, and internal services use private networking. Customer-supplied dependencies follow the networking configured for that deployment.
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

Application and sandbox workloads run with hardened security contexts, including non-root execution, restricted privilege, and CPU and memory limits. Cluster-level installers and other infrastructure components may require controlled host access to provide the sandbox runtime.

Sandbox isolation — one ephemeral sandbox per task, scoped access, egress whitelisting, automatic cleanup — and API-key handling are application guarantees, specified in the Security model and Sandboxes.

Security model: isolation, encryption, and credential handling across the deployment boundary.
Data handling: what agent-run data is held, residency, retention, and CMEK.
Organizations & projects: the tenancy model deployments sit beneath.