Security & Compliance for Self-Hosted Deployments

Self-hosting exists for one reason: your data and the keys that protect it never leave your control. Everything runs inside your own cloud account, in the region you choose, on infrastructure your team already governs. Confident AI operates none of it and has no path to it.

This page is written for a security review. It covers what data exists and where it lives, how it is encrypted, how the app authenticates to your cloud, how the network is isolated, what leaves your network and what does not, and how the deployment fits your compliance program.

The short version

Ownership and data residency

The Terraform module provisions the database, object storage, and cluster in your account and your chosen region. Because the data plane is yours:

• Data stays inside the geographic boundary you deploy to, which is what most data-sovereignty and GDPR requirements ask for.
• Confident AI cannot read, copy, or export your data. There is no shared control plane and no phone-home for application data.
• Deleting a deployment deletes the data with it. You own the lifecycle end to end.

What data exists and where it lives

Every store is a service Terraform created in your account. Nothing is stored outside it.

Encryption

Data is encrypted in transit and at rest using the cloud provider's native services. The encryption keys live in your account, and Confident AI never holds them.

Key management

Cloud-managed keys satisfy most requirements out of the box. Customer-managed keys add operational overhead but give you full custody and revocation.

Identity and access

The app authenticates to your cloud through the platform's own identity system, so there is nothing static to rotate or lose:

The permissions each role holds are scoped to exactly what the app needs (its own database, its own buckets, and the optional code executor). They are defined in the Terraform module, so you can read them before you apply and adjust them if your policy is stricter.

Image pull credentials

The one credential involved is the one that pulls the first-party container images from Confident AI's registry. The chart uses it only for image pulls, refreshes it on a schedule so it never goes stale, and it grants no access to your data or cloud APIs. For fully offline environments, images can be mirrored into your own registry so no external pull is needed.

Authentication and authorization

Users can sign in with email and password, Google OAuth, or your SSO provider over SAML or OIDC. Access controls:

• Require SSO: set config.disableNonSsoLogin: true to turn off password login and route every human user through your identity provider, which gives you centralized access control, MFA enforcement, and deprovisioning when someone leaves.
• API keys: programmatic access uses project-scoped keys. Each key is tied to a single project, is revocable at any time, and cannot change settings or act as a user.
• Roles: access is organized by project so teams only see the projects they are members of.
• Audit logs: user and administrative actions are recorded and viewable in the app, in addition to your cloud provider's own audit trail.

Secrets management

You have two supported ways to hold application secrets (the database URL, the auth signing secret, the LLM key, and the license key):

1. Cloud secret store with the External Secrets Operator (recommended for production): secrets live in AWS Secrets Manager, GCP Secret Manager, or Azure Key Vault, and ESO syncs them into the cluster using the same keyless workload identity described above. Rotating a value is a single write to the secret store, and ESO re-syncs on its own.
2. Kubernetes Secret: the chart renders a Secret from the values you provide. Suitable for smaller or air-gapped setups where a cloud secret store is not in play.

The ClickHouse password is a separate in-cluster secret in both cases. Secrets are never written to logs.

Network architecture

The module deploys into a VPC or VNet you already own, and the sensitive components sit on private IPs inside it:

• Nodes run in private subnets and reach the internet only through a NAT gateway.
• You choose a public cluster API endpoint (convenient for running kubectl and helm from your laptop) or a private-only endpoint reached through a bastion or VPN.
• You choose an internal ingress load balancer for a fully private deployment, or an internet-facing one with TLS for a normal web-facing setup. Neither is forced on you.

What leaves your network

Outbound traffic is limited and predictable:

If your egress is locked down, allowlist only the LLM endpoints you use (for example api.openai.com, *.openai.azure.com, or api.anthropic.com), or point evaluations at a self-hosted model so no external call is made at all. There is no telemetry or usage data sent to Confident AI.

Fully air-gapped deployments

For environments with no outbound internet access, Confident AI provides offline image delivery and self-hosted LLM options for evaluations, and the license key is validated inside your cluster with no license-server call-out. Talk to the platform team for an air-gapped rollout.

Software supply chain

• First-party images: every workload runs an image built and published by Confident AI, pulled from a single known registry.
• Version pinning: you pin the chart version (--version), which bundles a specific app release. Nothing updates on its own, and upgrades happen only when you run helm upgrade with a new chart version.
• License key: features are gated by a signed license key that is verified inside your cluster. It does not call out to a license server, and it cannot be used to reach your data.

Backups and durability

• Database: the managed PostgreSQL service takes automated backups and supports high availability (Multi-AZ on RDS, regional HA on Cloud SQL, zone-redundant HA on Flexible Server). Deletion protection is available and recommended for production.
• Object storage: S3, GCS, and Blob provide provider-level durability and versioning options.
• ClickHouse: runs on persistent volumes, with an optional backup bucket for exports.
• Redis: holds cache and queue state, not a source of truth, so it is safe to lose.

Auditing and logging

• Cloud-native audit: every action Terraform and the app take against your cloud is recorded by your provider's audit service (AWS CloudTrail, GCP Cloud Audit Logs, Azure Monitor), inside your account.
• Application audit logs: user and administrative actions are captured in the app.
• Workload logs: pod logs flow to your cluster logging and can be shipped to your existing log platform.

Compliance

Because the deployment lives inside your account and region, it fits into your existing compliance program rather than introducing a new processor to assess.

Retention and deletion are under your control: you decide how long traces, datasets, and logs are kept, and removing data is a direct operation against services you own.

Security review checklist

Before you approve a deployment, your security team can confirm each of these against the Infrastructure and Deploy guides:

• Cluster API endpoint set to public or private per your policy
• Ingress set to internal or internet-facing per your policy, with TLS on a certificate you control
• Database, cache, and object storage confirmed private
• Encryption keys reviewed (cloud-managed or customer-managed)
• Workload identity permissions reviewed in the Terraform module
• Secret store chosen (cloud secret store with ESO, or Kubernetes Secret) and rotation understood
• Authentication method chosen (SSO required, or email and OAuth allowed)
• Outbound allowlist approved for your LLM provider, or a self-hosted model selected
• Backup and retention settings match your requirements
• Audit log shipping wired into your existing platform

Next steps

Last updated on July 31, 2026