Trust you can verify,
not just take on faith.
Elixium runs on a hardened, signed container supply chain we build and maintain in-house — with FIPS-mode cryptography, a full bill of materials on every image, and provenance anyone can verify offline. The same platform, whether it runs in our cloud or inside your air-gapped enclave.
Security as a property of how it's built.
Hardened & minimal by construction
Our runtime images are distroless — no shell, no package manager, nothing but the runtime and the app. The attack surface collapses to almost nothing, and least-functionality is a property of how the image is built, not a policy applied after.
Signed, with a full bill of materials
Every image carries a cryptographic signature and a complete SBOM (software bill of materials), attached in the registry. Anyone can verify what is inside and that it came from us, unmodified — offline, without trusting a third party.
FIPS-mode cryptography, built in
Our FIPS image variants operate in FIPS mode with approved-algorithms-only enforcement, proven active on every build. This is the control implemented where the cryptographic work actually happens — inside the container.
Air-gap ready
The entire image set moves into a disconnected environment with signatures and SBOMs intact. Built for the enclave, where "just pull it from the vendor" is not an option. Full enclave deployment is in early access today.
Continuously rebuilt & scanned
Images are rebuilt on a cadence we control, so vulnerabilities are eliminated at the source rather than patched around. Each image ships with its scan report and severity scope — the claim carries its own evidence.
You hold the keys, and the capability
Self-hosted means you own the data, the database, and the encryption keys. And the supply chain itself is ours to run — not rented from a vendor subscription, so nothing about your trust chain depends on someone else’s roadmap.
Trusted in. Hardened, signed, FIPS-enabled out.
A closed loop we run end to end. Vetted components become hardened, verifiable images that Elixium — and only images we built and signed — is assembled from.
Approved algorithms only — and we prove it every build.
Our FIPS image variants ship a cryptographic module that operates in FIPS mode: non-approved algorithms are rejected, and the module runs its power-on self-test before the image is allowed to ship. It is the control implemented inside the container, where the cryptographic work actually happens — not a claim on a datasheet.
For programs that require a formal certificate, there is a clear upgrade path to a CMVP-validated cryptographic module. We'll name the module and the certificate for your assessment when a contract requires it.
Controls implemented by construction.
Evidence-producing controls that support CMMC and FedRAMP-adjacent programs — implemented in the artifact, not asserted in a document.
Humans approve, AI executes — as controls, not policy prose.
Every agent connects under its own OAuth identity. Everything it does is attributed, gated, and auditable — the same bar your human team ships through.
Control mappings indicate where our artifacts provide implementing evidence. Assessment and authorization decisions rest with your assessor and authorizing official.
Runtime & platform security
This page is about how Elixium is built. For how it behaves at runtime — OAuth 2.1, RBAC, tenant isolation, encryption in transit and at rest — see the platform security controls.
Deploying into a regulated or air-gapped environment?
Talk to us about self-hosted and FIPS-enabled Elixium, SBOM and signature verification, and what an air-gapped deployment looks like for your program.