> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cnap.tech/llms.txt
> Use this file to discover all available pages before exploring further.
# Security
> How CNAP isolates workloads, protects data, and keeps your infrastructure secure
CNAP is built for deploying software to customer infrastructure — hospitals, banks, enterprises with strict compliance requirements. Security isn't an add-on; it's foundational to the architecture.
## Architecture: your data, your infrastructure
Unlike platforms that host your workloads on shared infrastructure (Railway, Render, Fly.io), CNAP runs your applications on **your servers** or **dedicated clusters you control**.
```
Traditional PaaS: Your app → Shared servers (provider controls data)
CNAP: Your app → Your servers (you control data)
```
When a customer deploys through CNAP, application runtime data stays on the customer's infrastructure. CNAP's control plane stores configuration metadata (deployment settings, Helm values, resource names) but does not store or process the data your applications generate at runtime.
## Isolation model
### Per-customer cluster isolation
Every managed cluster is a fully isolated virtual cluster with its own:
* Kubernetes API server
* Isolated state store (separate from other clusters)
* RBAC and service accounts
* Certificate authority
Cluster state is isolated — one customer's workloads cannot see, access, or interfere with another customer's workloads. Each virtual cluster has its own API server and data store, even though they share the underlying management infrastructure.
### Workspace isolation
Workspaces are the organizational boundary in CNAP. Each workspace has:
* Separate Stripe billing (merchant account for marketplace sellers)
* Independent resource quotas
* Own cloud credentials (BYOM keys are workspace-scoped)
* Separate clusters, products, and deployments
## Data residency
With BYOM (bring your own machine), the customer controls where data lives:
* **Choose your cloud provider** — Hetzner (EU/US), AWS, GCP, or any supported provider
* **Choose your region** — Falkenstein, Frankfurt, Ashburn, or wherever your compliance requires
* **Data stays on your servers** — CNAP's control plane sends orchestration commands; it does not store or process customer application data
| Feature | What passes through CNAP | Customer data visible? |
| -------------------------------- | -------------------------------------- | ------------------------------------------------------------------ |
| **AI code execution** (Codemode) | Your code snippets + execution results | Yes — code you write is processed |
| **Custom dashboards** | Kubernetes API queries + responses | Only resource metadata (pod names, statuses), not application data |
| **Kubernetes API proxy** | `kubectl` commands + responses | Cluster metadata only — not application payloads or volumes |
| **Log streaming** | Container stdout/stderr | Depends on what your app logs — avoid logging sensitive data |
| **Preview domains** | HTTP traffic (TLS terminated at edge) | Request/response passes through Cloudflare, not CNAP servers |
These features are opt-in. If your compliance requirements prohibit any data leaving your network, you can use CNAP purely for orchestration and access your cluster directly via its kubeconfig.
For the strictest requirements, customers can run workers on their own on-premise servers. SSH into the server, run the [bootstrap command](/clusters/add-workers), and it joins the CNAP-managed cluster. Your data never leaves your network.
## Encryption
| Layer | Protection |
| --------------------------- | ----------------------------------------------------------------------------------------------- |
| **Control plane ↔ worker** | TLS with automatic certificate rotation |
| **API access** | HTTPS only, TLS 1.2+ |
| **Authentication** | OAuth2, session tokens, ServiceAccount JWTs |
| **Cloud credentials** | Stored as references to a secrets manager (actual tokens are never in the application database) |
| **Worker bootstrap tokens** | Short-lived, configurable expiry |
## Authentication and access control
* **Dashboard**: OAuth2 via GitHub, Google, or email magic link
* **API**: Personal Access Tokens (PAT) or OAuth2 Bearer tokens
* **Internal services**: Kubernetes ServiceAccount JWT with JWKS verification
* **Workspace membership**: Role-based (owner), scoped to workspace resources
## What CNAP stores vs. what stays on your infrastructure
**Stored by CNAP** (configuration metadata):
* Workspace settings, user accounts, billing state
* Product definitions, Helm chart references, deployment configurations
* Helm value overrides you configure in the dashboard
* Machine records, cluster metadata, quota usage counters
**Stays on your infrastructure** (runtime data):
* Your application runtime data (databases, files, user-generated content)
* Your container images (stored in your registry — CNAP only stores the image reference)
* Your Kubernetes secrets (stored in your cluster's isolated data store)
* Your cloud provider API tokens (stored as references to a secrets manager, not in CNAP's database)
## Compliance roadmap
CNAP does not yet hold SOC 2, ISO 27001, or other formal certifications. These are planned and in progress. We are transparent about our current state.
| Certification | Status | Timeline |
| --------------------------------------------- | ---------------------------------------------------------------------- | --------- |
| **GDPR** | Architecture supports EU data residency; formal assessment in progress | Current |
| **SOC 2 Type II** | Planned | 2026-2027 |
| **ISO 27001** | Planned | 2026-2027 |
| **DORA** (Digital Operational Resilience Act) | Under evaluation | TBD |
For enterprise customers requiring compliance documentation before formal certification, we provide:
* Architecture security review documentation
* Data flow diagrams showing isolation boundaries
* Infrastructure audit support (we participate in your vendor assessment)
* Custom DPAs (Data Processing Agreements)
## On-premise and air-gapped deployments
CNAP supports deploying to servers behind firewalls and in restricted networks:
1. The customer's server initiates an **outbound-only** connection to the CNAP control plane
2. No inbound ports need to be opened
3. The bootstrap command handles all setup (Kubernetes install, cluster join, certificate exchange)
4. Once connected, the worker communicates through a secure tunnel back to the control plane
This means hospitals, banks, and government agencies can use CNAP without exposing their infrastructure to the internet.
## Reporting vulnerabilities
If you discover a security vulnerability, please report it to **[security@cnap.tech](mailto:security@cnap.tech)**. We take all reports seriously and will respond within 48 hours.
## What's next?
Bootstrap command for connecting your own servers
Custom limits, compliance support, dedicated infrastructure
Where your workloads run
How traffic reaches your workloads