Test assisted setup on a fresh server

Use this path when you want to see Panocrypt set up encryption at rest, connect managed boot unlock, and show evidence through the console on a throwaway server.

This is the optional disk encryption setup path. If your server already uses LUKS, you do not need this setup helper; use an existing-LUKS bind path with your distro’s Clevis packages instead.

Read What runs on your server if you want the top-level split before provisioning a server. Read No custody of disk keys first if you want to understand why managed boot unlock does not give Panocrypt custody of the disk key.

What this proves

• Enrollment-key-based device registration from cloud-init/user-data.
• Panocrypt-assisted setup of a supported fresh provider image.
• LUKS setup and Panocrypt/Clevis binding for managed boot unlock.
• Reboot verification on the encrypted system.
• Allow, deny, optional manual approval, and unlock decision evidence.

Before you start

You need:

• A Panocrypt org with permission to create enrollment keys.
• A cloud account where you can create and destroy a small test server.
• SSH access or provider console access for recovery and inspection.
• A provider image listed in the assisted setup providers.

Good first targets:

Provider	Image	Why
Hetzner Cloud	Ubuntu 26.04 x86_64	Fast disposable test path. See Hetzner full disk encryption.
DigitalOcean	Ubuntu 24.04 x86_64	Stable disposable test path. Use a newer image only after it appears in assisted setup providers. See DigitalOcean full disk encryption.

Provider billing minimums apply. On small disposable servers, this is usually a short test, but the exact cost and billing interval are controlled by the provider.

Assisted setup test path

1. Create a one-device enrollment key in Panocrypt.
2. Copy the generated cloud-init/user-data.
3. Create a throwaway supported server and paste the cloud-init data.
4. Watch setup as the device enrolls and disk encryption setup runs.
5. Verify encrypted boot from the host.
6. Test the controls: disable managed unlock, allow one unlock, or require manual approval.
7. Clean up the cloud server and Panocrypt test device.

Create the enrollment key

In the Panocrypt console:

1. Open your org.
2. Go to Enroll -> Enrollment keys.
3. Select Create enrollment key.
4. In Enrollment details, name it fresh-server-test.
5. In Policy, choose Use each device’s registration IP for a simple disposable-server proof. Choose Specific sources if you already know the server source CIDR you want to allow.
6. Require manual approval for unlocks only if you want to test manual approval in this run.
7. In Reuse, choose One device and a short registration window, such as one day.
8. Review and create the key.
9. Copy Short CloudInit.

The generated user-data looks like this:

#!/bin/sh
set -eu
export PANOCRYPT_ENROLLMENT_KEY='...'
curl -fsSL https://downloads.panocrypt.com/install.sh | sh

Treat the enrollment key as sensitive bootstrap material. It authorizes a new device to register during the key’s registration window. The LUKS recovery passphrase is generated on the target during setup; do not put a recovery passphrase in cloud-init/user-data.

Create the server

Create a small supported server in your provider console.

For Hetzner Cloud:

1. Choose a small x86_64 server type.
2. Choose Ubuntu 26.04.
3. Add your SSH key.
4. Paste the Panocrypt Short CloudInit content into the cloud-init or user-data field.
5. Create the server.

For DigitalOcean:

1. Choose a small x86_64 Droplet.
2. Choose Ubuntu 24.04 x86_64.
3. Add your SSH key.
4. Paste the Panocrypt Short CloudInit content into the user-data field.
5. Create the Droplet.

Use only disposable infrastructure for this proof. Assisted setup modifies the root disk as part of setting up LUKS on the provider image.

Watch setup

Back in Panocrypt, the device should appear after enrollment. Open the device detail page and watch the assisted disk encryption setup progress.

In the console, look for these setup phases:

Phase	What is happening
Enroll device	The server registers with Panocrypt using the enrollment key.
Prepare setup	The target downloads the Panocrypt setup helper and validates the run.
Encrypt root disk	Panocrypt sets up LUKS on the supported image’s root disk.
Connect managed unlock	Clevis binds a LUKS keyslot to the Panocrypt device URL.
Verify encrypted boot	The server returns on encrypted root and reports evidence.

After setup, normal managed boot unlock uses LUKS, Clevis, the distro’s initramfs hooks, and Panocrypt policy. The setup helper is not a permanent unlock agent.

Preserve recovery material

The normal cloud-init/user-data path does not put a recovery passphrase in user-data. The setup path generates the passphrase on the target and writes it on the encrypted root:

/root/panocrypt-luks-recovery-passphrase.txt

Panocrypt does not store that passphrase and cannot show it later. Retrieve it, test it, store it outside Panocrypt, then remove the on-host copy. Use Assisted setup recovery material for the exact commands and cleanup guidance.

Do not delete the on-host copy until you have tested and stored the passphrase.

Verify encrypted boot

After setup completes and the server returns, SSH to the server and run:

sudo panocrypt disk verify
findmnt / -o SOURCE,FSTYPE
sudo cryptsetup status cryptroot
sudo cloud-init status --long

Expected signs:

Check	Expected result
panocrypt disk verify	Reports verification success.
findmnt /	Shows root mounted from /dev/mapper/cryptroot or an equivalent LUKS mapper source.
cryptsetup status cryptroot	Shows an active LUKS device.
cloud-init status --long	Shows setup finished without blocking cloud-init errors.

In Panocrypt, review the device activity and audit trail for the managed unlock and setup evidence.

Test the controls

After the server is bound and encrypted boot is verified, test the controls that matter for your rollout.

Control	What to do	What it proves
Disable managed unlock	Turn off Managed unlock, then reboot during a planned test window.	Panocrypt can deny future managed boot unlock for this device.
Allow once	Use Allow once before a planned reboot.	A narrow, one-use exception can let the next managed unlock proceed.
Require manual approval	Require manual approval for unlocks, reboot, then approve or deny from Maintain -> Manual unlock.	Operators can gate a managed unlock request before it proceeds.

Use Source IP and one-time unlocks for source policy and Allow once. Use Disable unlocks for the future-unlock boundary. Use Approval groups for approval policy.

Disabling managed unlock affects future network-bound recovery exchanges. It does not lock a server that is already running, remove keys from memory, modify the LUKS header remotely, or delete customer-held recovery material.

If you want a phone browser to receive manual unlock prompts, register it with the Mobile notifications guide before testing approval-gated unlock.

Clean up

When the test is complete:

1. Destroy the provider server.
2. Delete any attached volumes, snapshots, backups, or images created for the test.
3. Revoke or let the enrollment key expire.
4. Archive the Panocrypt device record if you do not need it for later evidence review.
5. Remove any local notes that contain enrollment tokens.

Proof result

You used a one-device enrollment key to let a supported disposable server register itself, set up LUKS on its root disk, bind managed boot unlock to Panocrypt, and report evidence after returning on encrypted root. You also saw where operators can allow, deny, or require approval for future managed unlocks.