Core Concepts

Building cloud-native applications typically requires teams to assemble and maintain a wide range of platform capabilities, from provisioning dependencies and managing credentials to enforcing network policy and configuring encryption. Over time, this complexity increases operational overhead and diverts engineering effort away from delivering application value.

ACRA simplifies this model by providing a secure, opinionated platform where these concerns are handled by default. Applications are deployed into isolated enclaves with ready-to-use supporting services and enforced security controls, allowing teams to focus on application behavior rather than platform assembly. Dependencies are provisioned as part of the enclave, communication is denied by default unless explicitly allowed, and encryption is applied automatically for data in transit and at rest.

By default, dependencies are provisioned as part of the enclave:

• Communication is denied unless explicitly allowed
• Secrets and keys are centrally managed
• Encryption is applied automatically for data in transit and at rest.
• All actions and access are recorded, providing full system auditability.

For technical leaders, ACRA provides a consistent execution environment that reduces platform complexity, lowers security risk, and supports both modern and legacy workloads without requiring application rewrites.

ACRA Enclaves

An ACRA enclave is an isolated execution environment designed to run one or more applications together with their required supporting services. Enclaves are the primary security and operational boundary within the platform, providing strong isolation between workloads while allowing controlled internal communication where explicitly permitted. Isolation boundaries are enforced at multiple layers, including compute, storage, and networking. Applications running inside an enclave cannot discover or communicate with other enclaves or external systems unless those paths are explicitly defined. This prevents lateral movement by default and significantly reduces blast radius, even when running legacy or unmodifiable applications.

Ingress and egress are tightly controlled at the enclave boundary. All inbound and outbound traffic is subject to explicit policy, with default-deny behavior enforced by the platform. This ensures that communication paths are intentional, auditable, and limited to what is strictly required for operation.

Isolation Boundaries

Each ACRA enclave is a hard isolation boundary, not a logical grouping.

Workloads inside an enclave are isolated from other enclaves at the container, pod, network, and data layers. Enclaves do not share identity, permissions, secrets, or application state, and there is no implicit trust or ambient access between them. While multiple enclaves may be scheduled on the same underlying node, communication and access are strictly controlled by policy. Where required, compute can be further separated using node-level placement controls. This model prevents lateral movement, limits blast radius during incidents, and allows sensitive workloads to operate side by side without cross-contamination.

Ingress and Egress Model

ACRA enforces explicit, policy-driven ingress and egress.

Nothing enters or leaves an enclave unless it is explicitly allowed. All inbound and outbound communication is routed through controlled interfaces where identity, authorization, and audit are enforced.

This applies equally to:

• Enclave-to-enclave communication
• Enclave-to-external systems
• External systems calling into an enclave

Every allowed path is defined, logged, and attributable. If a path is not declared, it does not exist.

Control Plane vs Enclave Plane

ACRA is split into two planes with a hard responsibility boundary: the control plane and the application plane. This separation ensures that platform operators can manage environments without gaining access to the data or logic inside them.

Responsibilities Split

The control plane is responsible for creating, configuring, and observing enclaves. It manages lifecycle, permissions, updates, and visibility, but it does not execute application logic or access workload data.

The enclave plane is where applications run. It executes business logic, processes data, and enforces runtime isolation and policy. The enclave plane does not control its own creation, identity model, or external permissions.

Valarian-Provided Services

ACRA provides a small, fixed set of core applications that can be deployed inside an enclave. These applications form the building blocks for higher-level operational use cases.

The available enclave applications are:

• Chat: Secure messaging for sensitive coordination and internal communications.
• File Storage (Data Store): Encrypted object and file storage for documents, artefacts, and operational data.
• Video Meetings: Secure real-time audio and video conferencing for distributed or mobile teams.
• AI: Self-hosted LLM and embedding workloads running entirely inside the enclave.

Each application runs as an enclave-native service and inherits the same isolation boundaries, access controls, and audit guarantees.

Customer-Owned Applications

Customers can deploy their own applications into enclaves alongside Valarian services.

Applications are packaged as containerised workloads and deployed through the ACRA control plane. Once launched, they operate entirely inside the enclave boundary with no implicit access to other services, data, or networks.

All communication, storage, and external access must be explicitly declared. If a dependency or integration is not permitted by policy, it is not reachable.

This allows your team to deploy bespoke mission workflows that run securely without sacrificing control or consistency.

Lifecycle and Observability

Application lifecycle is managed by the control plane, while observability is enforced inside the enclave.

Application Lifecycle Management

Applications are deployed, updated, and rolled back using ArgoCD. All changes are declarative, versioned, and auditable, allowing operators to manage application state without accessing application data or logic.

Metrics, Logs, and Traces

ACRA uses standard, interoperable observability components:

• Prometheus collects metrics for enclave applications and platform components.
• OpenTelemetry captures distributed traces across services and workflows.
• Loki aggregates application and system logs emitted by enclave workloads.

Visualization and Analysis

• Grafana provides a unified interface for visualising logs, metrics, and traces. Operators can assess health, performance, and trends in real time, as well as investigate historical behaviour during incident review.

Network Observability

Network behaviour is observable at multiple layers without exposing workload data:

• Cilium provides Layer 4 network observability and enforcement at the enclave boundary.
• Istio provides Layer 7 visibility into service-to-service communication and policy enforcement.
• Kiali and Hubble are used to visualise network traffic, flows, and isolation boundaries within and between enclaves.

Security and Compliance Monitoring

• Trivy is used for vulnerability scanning and compliance checks across images and deployed workloads, supporting continuous risk assessment and policy enforcement.

Together, these tools provide operators with assurance that systems are behaving as declared, while preserving strict separation between operational visibility and workload data access