Appearance
ACRA Platform

Deploy custom applications and workflows
ACRA provides a secure execution platform for running complete application environments inside isolated virtual enclaves. It replaces fragmented cloud services and brittle legacy hosting with a single hardened substrate designed for containment, access discipline, and resilience by default.
Teams can deploy custom, containerised applications and multi-step workflows without assembling platform plumbing. Required supporting services, such as databases, message buses, storage, and secrets, are provisioned within the enclave and governed by platform policy rather than application code.
ACRA is used to run:
Mission-specific applications
Secure data storage and processing
Agentic and LLM-assisted workflows
Internal collaboration
All workloads operate under explicit ingress and egress rules, strong identity controls, and built-in auditability.
Legacy Application Sunsetting
ACRA is well suited for isolating and containing legacy or high-risk applications that cannot be easily refactored or retired.
Instead of running legacy systems on flat networks or shared infrastructure, organisations can place them inside tightly scoped enclaves with restricted access, controlled dependencies, and limited blast radius. This enables:
Safe continuation during decommissioning or migration
Segmentation of fragile or untrusted systems
Audit and access controls without modifying application code
This approach reduces risk while avoiding forced rewrites or rushed retirements
ACRA Edge
Field-deployed secure enclaves
ACRA Edge extends the platform into a portable, field-deployable form factor. It allows organisations to run a full ACRA enclave locally, without reliance on fixed infrastructure or continuous cloud connectivity.
ACRA Edge enables:
Local execution of Valarian services and customer-approved applications
Secure internal communications during transit or relocation
Encrypted local data storage and processing
Continuity across power loss, shutdown, and movement
This makes it suitable for forward-deployed teams, mobile operations, search and rescue, and other environments where infrastructure cannot be trusted or assumed.
ACRA AI Subsystem
The ACRA AI subsystem enables organisations to run LLM and embedding workloads entirely inside secure enclaves. AI workflows operate under the same containment, identity, and audit guarantees as all other enclave applications, with no implicit external connectivity.
The subsystem is designed for multi-step, agentic workflows that operate on sensitive data while remaining observable and controllable by operators.
Supporting components include:
AuthN and AuthZ (Enclave Boundary): Authenticates users and enforces permissions before any workflow step can access data, models, or tools.
File-Sharing System and MCP Server: Provide structured, policy-enforced access to documents and artefacts through an MCP interface.
LLM Subsystem: Executes calls to one or more language models, constructs prompts, applies safety controls, and parses responses.
Vector Database: Stores embeddings to enable scoped retrieval of relevant context for each model invocation.
Postgres Database: Stores workflow definitions, execution state, and durable decision records for audit and recovery.
ClamAV for Storage and Virus Scanning: Stores uploaded and generated files and scans content before it is shared with users or downstream systems.
Platform Services: Provide logging, monitoring, security scanning, and key and secret handling across the workflow.
User: Initiates workflows by submitting requests or uploading content.
All components operate within the enclave boundary and inherit encryption, isolation, and audit guarantees
Control Plane Interaction
The ACRA control plane manages AI workflows without accessing model inputs, prompts, or outputs.
Control plane responsibilities include:
Deployment and Lifecycle Management: Deploying AI services into enclaves, managing updates, and controlling version rollout.
Permissions and Secrets: Managing platform configuration, access policies, and secret injection at deploy time.
Visibility: Publishing version, health, and status information so operators can verify system state.
This separation ensures operators retain control over AI deployment and availability while workload data remains confined to the enclave