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.Isolation model
Per-customer cluster isolation
Every managed cluster is a fully isolated with its own:- Kubernetes API server
- Isolated state store (separate from other clusters)
- RBAC and service accounts
- Certificate authority
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
Some optional features route data through CNAP — see details
Some optional features route data through CNAP — see details
| 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 |
For the strictest requirements, customers can run workers on their own on-premise servers. SSH into the server, run the bootstrap command, 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
- 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
| 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 |
- 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:- The customer’s server initiates an outbound-only connection to the CNAP control plane
- No inbound ports need to be opened
- The bootstrap command handles all setup (Kubernetes install, cluster join, certificate exchange)
- Once connected, the worker communicates through a secure tunnel back to the control plane
Reporting vulnerabilities
If you discover a security vulnerability, please report it to security@cnap.tech. We take all reports seriously and will respond within 48 hours.What’s next?
Add workers
Bootstrap command for connecting your own servers
Enterprise
Custom limits, compliance support, dedicated infrastructure
Compute providers
Where your workloads run
Networking
How traffic reaches your workloads