Lumes Enterprise · dedicated deployments

Run Lumes on infrastructureyou actually control.

The consumer build asks you to trust our relay for transport only — never with your keys or plaintext. Enterprise removes even that assumption: a dedicated, isolated instance, or your own hardware, where your organization holds the server, the database, the key custody, and the jurisdiction. Same twelve-layer cryptographic core. Zero shared tenancy.

Request a deployment Read the security model

01 — Who this is for

Teams where a leaked message is an operational failure, not a PR one.

Not industries — situations. These are the moments where the network itself is hostile, the metadata is the secret, and there is no acceptable margin for a vendor's promise.

Governments & political leadership

Cabinets, ministries, and elected officials — where a leaked group thread is tomorrow's headline and a hostile state hacking the last campaign is the baseline, not the worst case. A sovereign deployment keeps the keys, the server, and the jurisdiction inside your government.

Breach-response teams

When your own network is compromised, you need a channel the intruder provably isn't sitting on. Out-of-band coordination for the people containing a live incident.

Pre-announcement deal rooms

M&A, IPOs, and board moves where a single leaked line is an SEC filing and a dead deal. Provable retention, nothing parked in a shared store.

Diplomatic missions & field stations

Operating on infrastructure inside a host nation that is also the adversary. Data residency and air-gap on hardware your own people carry.

Investigative desks & source intake

Whistleblower channels where the metadata graph is the story. Sealed-sender identities, with custody your counsel holds — not a vendor.

Critical-infrastructure control rooms

Grid, water, and industrial operators coordinating through an attack on the very systems that would normally carry the message.

Protected-person programs

Witness protection and at-risk relocation, where an identity leak is a physical-safety event — not a privacy footnote.

02 — Deployment models

Three boundaries. You choose where yours sits.

Every tier runs the identical client and the identical twelve-layer stack. What changes is who holds the infrastructure — and how far the trust boundary extends away from us and toward you.

Available today

Tier 01

Dedicated instance

An isolated Lumes relay provisioned for your organization alone — your subdomain, your database, zero shared tenancy with consumer traffic.

Isolated server + database — no co-tenant data

Your subdomain (e.g. msg.your-org.gov)

Managed and patched by us; you hold every key

Organization-scoped Key Transparency log

In development

Tier 02

On-premises

The relay runs on your hardware, inside your network. Air-gap-capable, with no required egress to any external service — including ours.

Your hardware, your network perimeter

Air-gap capable — no external egress required

You control patch cadence and uptime

Push relies on your infrastructure, or is disabled

In development

Tier 03

Sovereign

On-prem plus full jurisdictional control: data residency in your territory, an independent third-party audit of your deployment, and a legal boundary your counsel defines.

Data residency in your jurisdiction

Independent third-party security audit

Hardware-backed (HSM) key custody (roadmap)

No vendor lever over your data — by construction

03 — How a deployment works

From key ceremony to first message.

A deployment is a sequence of trust-narrowing steps. Each one moves a little more control out of our hands and into yours — until the only thing we can touch is ciphertext in motion.

01 · Key ceremony

Your organization generates its root of trust offline. We never see it — no escrow, no recovery key on our side. Lose it and we genuinely cannot read your data. That's the guarantee, not a limitation.

02 · Provisioning

Administrators enroll members by attested public key — not a phone number, not an email. An identity is a key your org vouches for, published to a Key Transparency log scoped to your deployment alone.

03 · Device enrollment

Each device proves its integrity before it receives any key material. Rooted, jailbroken, emulated, or debugger-attached devices are refused by policy, not by a warning the user can dismiss.

04 · Operation

Every message rides the full twelve-layer stack. The relay — yours or ours — only ever moves ciphertext and a rotating recipient hash. Plaintext lives only on enrolled devices, in masked memory that zeroes on background.

04 — The trust boundary

What you hold — and what we never touch.

Consumer messengers ask you to trust a vendor's promise. Enterprise replaces the promise with architecture: the things that matter never cross into our control in the first place.

Your organization holds

We never hold

Key custody

Org root + per-user identity keys, hardware-bound on each device

Any private key, ever — the relay only ever sees ciphertext

Server & database

Your instance, your retention policy, your backups

A copy of your message store on shared infrastructure

Provisioning

Org-controlled onboarding via attested keys — no phone numbers

A phone-number or email directory mapping users to identities

Logs

Redacted-by-default, retention you set

Plaintext metadata logs or who-talks-to-whom graphs

Audit

Full architecture & threat-model documentation, plus the independent audit report

A black box you're asked to take on faith

Legal process can only extract what a party actually holds. On a sovereign deployment your organization holds both the keys and the server — so a demand served on us returns ciphertext we cannot decrypt, and a demand served on you is yours to answer, under your own counsel and jurisdiction. We didn't build a warrant canary. We removed the data that would make one necessary.

05 — Inherited core

The same twelve layers. Organization-grade enforcement.

Enterprise doesn't fork the cryptography — it inherits the full consumer stack and lets your administrators enforce it as policy rather than leave it to per-user choice.

Every layer — X25519, Ed25519, the XSalsa20 / XChaCha20 envelopes, HKDF, Argon2id, the full Double Ratchet, group sender keys, ML-KEM-768, ML-DSA-65, the Key Transparency log, and the anti-forensic stack — ships identically on enterprise. The per-layer breakdown lives on the security page.

See all twelve layers →

Security as policy — not per-user hope.

Enterprise hands your administrators a policy engine. The protections a consumer opts into individually become organization-wide guarantees you can prove.

Mandatory post-quantum — ML-KEM-768 + ML-DSA-65 enforced org-wide, with no downgrade path for any member.

Org-scoped Key Transparency — a log pinned to your deployment, with consistency proofs your own team can verify.

Device-attestation policy — block rooted / jailbroken / emulated / debugged devices before a single key is issued.

Retention & disappearing-message floors — set a maximum message lifetime no member can exceed.

Revocation with forward secrecy — removing a member rotates group keys so prior plaintext stays permanently unreachable.

Remote forward-secure wipe — a lost or seized device is zeroed at the key level, not just the message text, on next contact or by local duress policy.

06 — Status — no overselling

What ships today vs. what's in development.

Today: dedicated isolated instances, the full twelve-layer stack, org-scoped Key Transparency, and mandatory post-quantum enforcement.

In development: turnkey on-prem installer, air-gapped sovereign tier, HSM key custody, and SSO / SCIM provisioning. The external security audit is pending (Q3 2026). We won't claim a control before it ships.

Talk to us about a deployment.

There's no self-serve checkout and no public price list yet — enterprise deployments are scoped to a real threat model, not a seat count. Tell us what you're protecting, and against whom.

Deployments are scoped individually. Pre-audit build — external audit pending Q3 2026.

Compare vs Signal & Threema Security model Contact the team