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.
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.
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.