What runs on your server

Panocrypt has two separate jobs.

The first job is managed unlock. Panocrypt decides whether it should participate when a LUKS device asks to unlock, then records that decision. This is the core control-plane value: source policy, manual approval, one-time unlock, audit history, and managed unlock revocation.

The second job is optional disk encryption setup. Use it when a supported fresh provider image starts from an ordinary provider image that does not use LUKS yet, and you want Panocrypt’s setup helper to do the careful setup work for you.

Managed unlock

Managed unlock is Panocrypt’s first job.

If your server already uses LUKS, you can use Panocrypt without installing Panocrypt software on the host. Bind an unused LUKS keyslot with your distribution’s cryptsetup, Clevis, and the standard Clevis tang pin.

Panocrypt provides the unlock URL, signed public key material, policy decision, recovery exchange, and unlock decision evidence. Your host still uses the Linux encryption stack it already trusts.

Managed unlock gives you:

• Source IP and CIDR policy.
• Source allowlists.
• Manual approval.
• One-time unlock.
• Disable and re-enable managed unlock.
• Unlock attempt and decision history.
• A non-escrow recovery exchange.

This is the path to start with when you already know LUKS, already have an encrypted server, or want the smallest trust proof.

Disk encryption setup

Disk encryption setup is the optional second job.

Use it when the server is not already encrypted and you want Panocrypt to handle the supported setup work: prepare LUKS, connect managed boot unlock, verify encrypted boot, and get out of the core unlock path.

After setup, normal boot unlock uses LUKS, Clevis, the distro’s initramfs hooks, and Panocrypt policy. The setup helper is not the core unlock mechanism.

The setup helper only supports provider images that Panocrypt has already tested for this workflow. It is not a promise that every Linux image can be set up safely. See Assisted fresh-server setup for the setup model and Assisted setup providers for provider-specific setup paths.

What touches the host

Path	What runs on the server	Use it when
Existing-LUKS bind	Uses distro cryptsetup, Clevis, and the Clevis tang pin. No Panocrypt host agent is required for the bind or unlock path.	The volume or root disk already uses LUKS, or you want to bind manually.
Temporary LUKS proof	Uses distro cryptsetup and Clevis on a disposable file-backed LUKS volume. No Panocrypt installer or host agent runs.	You want the smallest proof before touching real infrastructure.
Assisted disk encryption setup	Uses the Panocrypt setup helper temporarily on a supported fresh provider image, then leaves future boot unlock to LUKS, Clevis, initramfs, and Panocrypt policy.	The server starts unencrypted and you want guided setup instead of hand-rolling the encryption setup.

Do not read the setup helper as a trust requirement. It exists for teams that want Panocrypt to operationalize the hard setup work on supported targets. If you can already set up LUKS yourself, bind the resulting LUKS device through the existing-LUKS path.

Choose a starting path

Start with Test a temporary LUKS volume if you want to prove Panocrypt-managed unlock with no boot-disk risk and no Panocrypt host software.

Start with Existing LUKS volume if you already have a real encrypted data volume and want to bind it with distro tools.

Start with Existing LUKS root disk if your root disk is already encrypted and you are ready to handle initramfs networking, CA certificates, and recovery access.

Start with Test assisted setup if you want to see the full guided setup on disposable infrastructure.

Use assisted setup providers for search-specific setup paths: Hetzner, DigitalOcean, OVH, and Oracle Cloud.

Read LUKS keyslots and Panocrypt binding to see why the Panocrypt binding is removable and why customer-held recovery material stays separate.