ACRA Platform Layers

ACRA separates infrastructure, platform services, and customer workloads into distinct layers. Each layer has a defined responsibility, lifecycle owner, and security boundary.

This separation ensures that customer applications operate in isolated environments while still being able to rely on shared platform services where appropriate.

The platform is organised into three primary layers:

1. Core Layer
2. Control Plane
3. Execution Plane

Each layer exposes controlled interfaces to the layer above it while restricting direct access to internal components.

Key Takeaways

• Platform management and workload execution are separated
• Customer workloads run inside isolated enclaves
• Platform services are shared but lifecycle-controlled
• Core infrastructure is inaccessible to applications

Core Layer

The Core Layer contains the foundational infrastructure components required for the ACRA platform to operate.

This layer is treated as an internal subsystem. It is isolated from customer workloads and platform applications and is only updated through Valarian-managed system releases.

Only the Control Plane interacts directly with the Core Layer. Components in the Execution Plane have no direct access to it.

The Core Layer provides the capabilities required to operate the platform securely and reliably, including:

• Networking enforcement
• Orchestration
• Storage
• Observability
• Secrets management

Core Layer Components

Component	Function
Cilium	Network security enforcement and network observability
ArgoCD	GitOps-based platform orchestration
HAProxy	Internal load balancing
Traefik	Ingress traffic control
Istio	Service mesh and encrypted service communication
Vault / OpenBao	Secret storage and credential management
Rook + Ceph	Distributed object storage
Prometheus	Platform observability and monitoring

Additional components are defined in the ACRA platform deployment configuration.

From the perspective of platform users and application developers, the Core Layer behaves as a black-box subsystem. Configuration changes occur only through controlled platform updates.

Control Plane

The Control Plane provides the platform-level services used to manage and support workloads running on ACRA.

Unlike the Core Layer, which provides foundational infrastructure, the Control Plane exposes operational services that applications and enclaves may rely on.

These services provide shared capabilities such as:

• Identity management
• Database services
• Messaging systems
• Security tooling

Applications running in the Execution Plane may access many of these services but cannot modify them or control their lifecycle.

Control Plane Components

Component	Function
Keycloak	Identity provider and authentication service
Application Registry	Repository for deployable applications
Plugin Registry	Repository for platform extensions
KubeVirt	Virtual machine execution engine
Audit Server	Platform activity logging and audit trail
ClamAV	Malware detection and scanning
Postgres	Relational database service
Redis	In-memory data store
NATS	Event messaging and service communication bus

These services form the shared platform capabilities available to application environments.

For example, an application running in the Execution Plane may use the platform-provided Postgres database or NATS messaging system rather than deploying its own instance.

However, the lifecycle of these services remains controlled by the Control Plane.

Execution Plane

The Execution Plane contains the application workloads deployed by customers and Valarian solutions.

This layer hosts the software that performs operational tasks, processes data, and delivers system functionality.

Applications run inside secure enclaves, which enforce isolation between workloads and restrict network communication to explicitly defined policies.

Example Workloads

Execution Plane workloads may include:

• Custom customer applications
• AI and LLM workflow systems
• Data processing pipelines
• Internal communication services
• Valarian applications such as PrivComms

Applications may choose to:

• Use shared services provided by the Control Plane, or
• Deploy and manage their own supporting services inside the enclave

This flexibility allows applications to remain portable while still benefiting from platform-level capabilities when appropriate.

Layer Interaction Model

Each layer interacts only with the layer directly below it.

This controlled dependency model prevents workloads from interacting directly with infrastructure components.

Layer	Interacts With
Execution Plane	Control Plane services
Control Plane	Core Layer infrastructure
Core Layer	Internal platform subsystems

This structure ensures that application environments remain isolated from infrastructure components while still benefiting from platform services.

50%

Security Boundaries

The layered architecture enforces multiple isolation boundaries.

Core Layer Isolation

The Core Layer is inaccessible to customer workloads and platform users. It is managed exclusively through controlled platform updates.

Control Plane Governance

Control Plane services provide shared capabilities while maintaining strict lifecycle ownership.

Execution Plane applications may consume these services but cannot alter their configuration or operation.

Execution Plane Containment

Customer workloads run inside enclaves with enforced network policies and resource isolation.

Applications cannot access other enclaves or platform infrastructure unless explicitly permitted.

This layered separation:

• Limits the blast radius of failures or compromise
• Preserves platform security guarantees
• Allows each layer to evolve independently