Skip to main content
Your data sits inside nested isolation layers — workspace and virtual cluster — wrapped by token auth, a reference-only secret store, and an audit log.
Akua is built for deploying software into isolated customer environments: Akua-managed machines, BYOM machines in your cloud account, manually attached workers, and imported clusters. Security is foundational to the architecture, not an add-on, and the exact data path depends on the deployment mode and features you enable.

​
Your data path depends on compute mode

Unlike platforms that run every workload on one shared application runtime, Akua separates the platform control plane from the worker environment where applications run.
On Akua-managed machines, workloads run on dedicated machines Akua provisions in its managed provider account. With BYOM, manually attached workers, or imported clusters, workloads run in infrastructure you own or operate. In all modes, Akua’s control plane stores configuration metadata such as deployment settings, chart values, and resource names so it can operate the platform.

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

​
Deployment modes

​
Managed control plane

Today, Akua operates the control plane for the platform. That means Akua handles orchestration, policy, and workspace state. Runtime data stays in the worker environment for the selected compute mode unless you enable a feature that routes specific traffic or output through Akua.

​
Customer workers and imported clusters

You can keep workloads on customer-owned workers, dedicated workers, or imported clusters. In those setups, the worker side of the deployment remains in your environment, and Akua only receives the platform data needed to manage it.

​
Secrets and credentials

Akua uses a workspace-scoped secret store for runtime credentials. This applies to cloud provider API keys, container registry credentials, webhook signing secrets, and agent provider keys. Key properties of the secret store:
  • Plaintext is never stored in configuration metadata. Secret values are stored in an external secrets manager; Akua keeps only a reference.
  • Versioned rotation. Secrets support append-only versioning: rotate by adding a new version and moving the current alias. Previous versions are accessible until explicitly disabled or destroyed.
  • Separate access scope. Reading secret metadata (secrets:read) and reading plaintext (secrets:access) are separate scopes. Every plaintext access attempt is audited.
  • Soft delete with recovery. Deleted secrets enter a 30-day recovery window before permanent removal.
See the Secrets API → for the full resource model.

​
Data residency

BYOM is Akua’s bring-your-own-machine path. For managed machine provisioning, you configure it with a cloud provider key so compute runs in your cloud account instead of Akua’s provider account:
  • Choose from supported providers: Akua-managed and BYOM machine provisioning use the providers available in your dashboard. Hetzner Cloud is available today.
  • Run your own workers where you need them: manually attached workers and imported clusters can run in the regions and environments you operate.
  • Keep runtime data in the worker environment: Akua’s managed control plane sends orchestration commands, but it does not need direct access to your application data unless you enable a feature that explicitly processes it.
These features are opt-in. If you want to minimize routed data, keep them off and access your cluster directly via its kubeconfig.
For the strictest requirements, customers can run workers on their own on-premise servers. Run the bootstrap command → and the server joins Akua’s managed cluster. Keep optional features disabled if you need runtime data to remain inside your environment.

​
Encryption

​
Authentication and access control

  • Dashboard: OAuth2 via GitHub, Google, or email magic link.
  • API: Workspace API tokens or OAuth2 Bearer (JWT) tokens.
  • Internal services: Kubernetes ServiceAccount JWT with JWKS verification.
  • Workspace membership: Role-based (owner), scoped to workspace resources.

​
What Akua stores versus what stays on your infrastructure

Stored by Akua (configuration metadata):
  • Workspace settings, user accounts, billing state.
  • Product definitions, Helm chart references, installation 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) in the selected worker environment.
  • Your container images (stored in your registry; Akua 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 an external secrets manager, not in Akua’s configuration database).

​
On-premise and air-gapped environments

Akua supports deploying to servers behind firewalls and in restricted networks:
  1. The customer’s server initiates an outbound-only connection to the Akua 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 Akua without exposing their infrastructure to the internet.

​
Compliance roadmap

Akua 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, Akua provides:
  • Architecture security review documentation.
  • Data flow diagrams showing isolation boundaries.
  • Infrastructure audit support (we participate in your vendor assessment).
  • Custom DPAs (Data Processing Agreements).

​
Reporting vulnerabilities

If you discover a security vulnerability, report it to security@akua.dev. We take all reports seriously and will respond within 48 hours.

Add workers

Bootstrap command for connecting your own servers.

Bring your own cloud

Ownership model for managed control planes, customer workers, and BYOM credentials.

Secrets API

Manage workspace secrets and credential rotation.

Private container registries

Keep image credentials scoped to your workspace.