# 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](https://docs.panocrypt.com/setup/existing-luks-volume/) with your distro's
Clevis packages instead.

Read [What runs on your server](https://docs.panocrypt.com/concepts/managed-unlock-vs-setup/)
if you want the top-level split before provisioning a server.
Read [No custody of disk keys](https://docs.panocrypt.com/trust/non-escrow/) 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](https://docs.panocrypt.com/providers/).

Good first targets:

| Provider | Image | Why |
|---|---|---|
| Hetzner Cloud | Ubuntu 26.04 x86_64 | Fast disposable test path. See [Hetzner full disk encryption](https://docs.panocrypt.com/providers/hetzner-automatic-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](https://docs.panocrypt.com/providers/digitalocean-automatic-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](#create-the-enrollment-key) in
   Panocrypt.
2. Copy the generated cloud-init/user-data.
3. [Create a throwaway supported server](#create-the-server) and paste the
   cloud-init data.
4. [Watch setup](#watch-setup) as the device enrolls and disk encryption setup runs.
5. [Verify encrypted boot](#verify-encrypted-boot) from the host.
6. [Test the controls](#test-the-controls): disable managed unlock, allow one
   unlock, or require manual approval.
7. [Clean up](#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:

```sh
#!/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:

```text
/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](https://docs.panocrypt.com/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:

```sh
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](https://docs.panocrypt.com/operations/source-ip-and-one-time-unlocks/)
for source policy and **Allow once**. Use
[Disable unlocks](https://docs.panocrypt.com/operations/disable-unlocks/) for the future-unlock boundary.
Use [Approval groups](https://docs.panocrypt.com/operations/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](https://docs.panocrypt.com/operations/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.