We should not have to pay the Big Cloud tax to get easy, auditable disk encryption.
That is the idea behind Panocrypt.
Fraudmarc built Panocrypt because we needed more freedom in selecting infrastructure providers. Some workloads belonged on Hetzner. Some on DigitalOcean GPUs. Some on OVH cloud regions across the US. One project was so bandwidth-heavy that Big Cloud’s egregious egress fees forced the move.
Our teams were ready to move beyond Big Cloud.
Our encryption-at-rest workflow was not.
Panocrypt is not a new disk encryption format. It is not a LUKS replacement. It is not a remote vault full of disk keys.
It is the missing operational layer around native Linux encryption.
LUKS rips
Linux disk encryption is incredibly powerful.
LUKS is solid. dm-crypt is solid. Clevis is solid.
LUKS manages encrypted volumes. dm-crypt does the block-device encryption. Clevis handles automated unlock. These are battle-hardened pieces built on boring, well-reviewed primitives.
Where’s the operational layer around it?
Big Cloud has made encryption-at-rest and surrounding security controls feel effortless. You get the control plane: provisioning defaults, key lifecycle, policy, audit trails, deprovisioning workflows, compliance evidence, and enterprise key-management patterns.
Panocrypt gives us that same basic posture using native Linux encryption primitives.
Outside Big Cloud, encrypted Linux servers have always been possible but painful.
They too often felt like a special project.
We had done the manual version: rescue mode, LUKS setup, changes to the early boot environment (initramfs), remote unlock, recovery docs. It works for one server, and it is exciting to SSH into initramfs with Dropbear and unlock your disk for the first time (after bricking your first few attempts). That does not become the default for a fast-moving team.
Here was the goal:
- Full-disk encryption by default
- Stock cloud-provider images
- Provisioning through cloud-init, Terraform, and infrastructure as code (IaC)
- Policy-based automatic unlock for unattended reboots
- No proprietary disk crypto
- No replacement for LUKS
- No custody of disk keys
- Normal LUKS recovery paths
- Manual unlock approval when needed
- Audit logs for unlock attempts and decisions
- Easy revocation during deprovisioning
- No custom agent required for the core flow
Policy
Panocrypt’s most important job is deciding whether it should participate in a disk unlock.
The policy can include:
- Device identity
- Tags, environment, or workload class
- Source IPv4 or IPv6 address
- Source network or Classless Inter-Domain Routing (CIDR) block
- Current registered IPs
- One-time unlock permission
- Manual approval
- Revocation state
- Optional enterprise-held approval or key controls
Any server with a stable IPv4 or IPv6 address can be allowed to unlock only from those addresses. An autoscaled pool can use approved CIDRs. A particularly sensitive machine can require human approval.
One-time unlocks make maintenance faster. Pre-approve the reboot you expect, let the machine come back, then return to a locked-down state without leaving a broad policy open.
Manual approvals can show the device and source IP requesting unlock. Unexpected requests can be denied and recorded. Specific users or groups can be allowed to approve specific classes of machines.
Every unlock attempt can become an audit record: device, source IP, policy result, approval state, and time.
Because Fraudmarc has spent years in email authentication, the analogy that comes naturally to us is Sender Policy Framework (SPF).
SPF says: these IPs are allowed to send mail for this domain.
Panocrypt says: these IPs are allowed to participate in unlocking this disk.
The boot-time question becomes:
Does this device, from this network location, under this policy, have permission to participate in this unlock?
Enrollment keys & the temporary bootstrapper
Enrollment keys make this fit normal provisioning.
You can place one in cloud-init, Terraform user data, an image build step, or run it manually on a new server:
#!/bin/sh
set -eu
export PANOCRYPT_ENROLLMENT_KEY='0000-00000-000'
curl -fsSL https://downloads.panocrypt.com/install.sh | sh
An enrollment key is not an unlock credential.
It does not unlock existing disks.
Think of it as scoped provisioning authority. Its job is to mint a new Panocrypt device inside an organization, attach the right defaults, and start the full-disk encryption upgrade on that machine.
Those defaults can include tags, environment, workload class, manual-approval requirements, registered source IPs, CIDR policy, ephemeral-device behavior, or other baseline controls.
That makes autoscaling and disposable infrastructure manageable. A new machine can come up from a stock provider image, inherit policy from the enrollment key, register its current network identity, and become its own Panocrypt-managed device.
Then the temporary bootstrapper performs an in-place upgrade to full-disk encryption.
It installs and configures the distro-native encryption pieces, enrolls the device with Panocrypt, binds one LUKS key slot to Panocrypt’s policy-controlled unlock path, updates initramfs, encrypts the entire server, and gets out of the way.
No permanent Panocrypt agent is required for the core unlock flow.
If a server already uses LUKS, you do not need the bootstrapper. You can use Clevis to bind an existing LUKS device directly to Panocrypt’s policy-controlled unlock path and keep your existing disk layout.
Each enrolled Panocrypt device can have its own policy, tags, revocation state, rotation path, and audit trail.
Binding
If you know Red Hat’s Network-Bound Disk Encryption (NBDE) model, this will feel familiar.
Panocrypt uses the distro-native Clevis client flow and is wire-compatible with the NBDE/Clevis handshake. Both initial disk binding and boot-time unlock can use what already ships with supported modern distros instead of a custom Panocrypt agent inside initramfs.
Binding creates a cryptographic dependency, not a custody relationship.
Panocrypt is one side of a McCallum-Relyea exchange: elliptic-curve Diffie-Hellman (ECDH)-derived binding material at setup, and a blinded ECDH recovery step at unlock. That lets Panocrypt help with unlocking without becoming a remote disk-key locker.
During initial binding, the Clevis client talks to Panocrypt and receives the public exchange material for this Panocrypt device. Panocrypt scopes that exchange material per enrolled device, giving policy and revocation a per-device cryptographic handle.
On the server to be enrolled, Clevis creates a new high-entropy local unlock key, adds it to a LUKS key slot, and wraps that unlock key as a JSON Web Encryption (JWE) object from the JavaScript Object Signing and Encryption (JOSE) family of formats.
To do that wrapping, Clevis combines Panocrypt’s public exchange material with fresh client-side private material and derives local wrapping material for the JWE. After the local unlock key is wrapped and stored with the LUKS header, Clevis discards both the derived wrapping material and the private material it would need to recreate that wrapping material alone.
Panocrypt does not receive the LUKS passphrase.
It does not receive the local unlock key.
It does not store a disk key to hand back later.
The unlock key is born on the machine, wrapped on the machine, stored on the machine, and never handed to Panocrypt.
Panocrypt stores policy, audit records, device identity, and its side of the per-device cryptographic relationship. The disk stores the encrypted unlock metadata.
Neither Panocrypt nor the local encrypted metadata, by itself, has a usable disk key.
Boot-time unlock
At boot, the Linux distro’s native Clevis code runs inside initramfs.
It reads the local encrypted unlock metadata from the LUKS header and asks Panocrypt, over Transport Layer Security (TLS), to participate in the McCallum-Relyea recovery exchange.
Classic NBDE operates over plain HTTP because the protocol is not downloading a disk key. The values on the wire are public or blinded cryptographic material, not a transported disk secret.
Panocrypt uses TLS because this happens over the public internet and the unlock request carries organization identity, device identity, and policy context. TLS protects the request context. McCallum-Relyea protects the disk secret.
Panocrypt evaluates policy before it participates:
- Is this Panocrypt device allowed?
- Is the request coming from an approved IP or CIDR?
- Was this device created through an enrollment key with the right policy?
- Has the device been revoked?
- Does this unlock require manual approval?
- Is this a one-time unlock?
If policy allows the request, Panocrypt returns its half of the blinded ECDH recovery.
That response is not a disk key. It is not the local unlock key. It is not useful by itself.
The local encrypted metadata is not enough by itself, either.
The Clevis client needs both:
- Its local encrypted unlock metadata
- Panocrypt’s policy-approved cryptographic response for this request
Together, those let the Clevis client reconstruct the wrapping material, unwrap the local unlock key from the JWE, and open the Panocrypt-bound LUKS key slot.
If policy denies the request, Panocrypt does not participate.
The disk remains locked unless you have a break-glass passphrase or another recovery path on a separate LUKS key slot. The machine hangs in initramfs, retrying the automatic unlock or awaiting a manual unlock, because its root partition is cryptographically inaccessible.
Safer deprovisioning
Without encryption, deprovisioning is often a checklist:
- Stop services
- Delete secrets
- Run a wipe script
- Trust that the wipe completed
- Trust the provider lifecycle
- Document what happened
With encrypted disks, you still can wipe. You still can run blkdiscard. You still can destroy the LUKS header. Some policies will require those things.
But you also get a cleaner control point:
Revoke Panocrypt unlock rights, then shut down or reboot to clear the LUKS key from memory. From that point, the Panocrypt-bound unlock path can no longer unlock the disk; access requires a separate recovery key slot or another deliberate recovery path.
Panocrypt operationalizes LUKS
On supported images, a server can start from a normal cloud image, enroll through a small cloud-init snippet or infrastructure-as-code flow, convert its root disk to the distro’s normal LUKS encrypted storage, and bind one LUKS key slot to policy-controlled remote unlock.
Reboots can unlock the disk automatically when policy allows. Panocrypt’s temporary bootstrapper is removed.
Manual recovery can still live outside Panocrypt.
Panocrypt does not replace LUKS. It does not store disk keys.
dm-crypt transparently encrypts and decrypts the disk. LUKS manages the encryption keys. Clevis binds a LUKS key slot to Panocrypt.
Panocrypt adds provisioning, policy, auditability, and revocation.
If you already have LUKS on a server, you do not need the bootstrapper or a permanent Panocrypt agent. Clevis can bind an existing LUKS key slot to Panocrypt’s policy-controlled unlock path.
If you stop using Panocrypt, remove the Panocrypt-bound LUKS key slot.
Ordinary Linux full-disk encryption does the heavy lifting.
Cloud freedom
Encryption-at-rest was a Big Cloud moat that kept too many of our workloads locked in.
Now that disk encryption is easy, auditable, and portable, our teams can place workloads where they belong. Panocrypt operationalizes full-disk encryption so that it can be the default everywhere Linux runs.
We move fast on alternative infrastructure without leaving the security behind.
That might be Hetzner for bandwidth-heavy systems.
DigitalOcean or other GPU clouds for AI workloads.
Dedicated servers for predictable capacity.
Temporary fleets for testing, probes, or regional experiments.
Or Big Cloud, when Big Cloud is the right answer.
Boring encryption, everywhere
We needed full-disk encryption to be boring across the infrastructure providers that fit our specific workloads. So did everyone else we asked.
Fraudmarc spent the past decade making email authentication easier, cheaper, and more operationally sane for clients and open source users. Now we’re bringing that same posture to Linux full-disk encryption.
If you have workloads that would run beautifully on Hetzner, DigitalOcean, GPU clouds, dedicated servers, OVH, or other specialized providers and you need easy, auditable encryption-at-rest, sign up for early access at panocrypt.com.
Full-disk encryption should be boring.
Not just inside Big Cloud.
Everywhere Linux runs.
