Skip to main content
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.
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 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
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, and it joins the CNAP-managed cluster. Your data never leaves your network.

​
Encryption

​
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.
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. 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