Encrypted server disk with a key only you hold

With this option, your server's root disk is encrypted with a passphrase that only you know. You set it up inside the server, and you unlock the disk yourself every time the server boots. Impreza never receives or stores the passphrase, and it keeps no recovery key. All it receives is what the Impreza agent on your server reports: whether the root is encrypted or waiting to be encrypted, how many unlock keys are allowed (never which ones) and the fingerprint of the unlock host key.

Availability: the encrypted-disk Ubuntu 24.04 image this guide starts from is still being rolled out and is not yet offered when you order or reinstall a VPS. Until it appears there, you cannot set up an encrypted server by following this guide, and we do not support installing the encryption tools by hand. This page will say so here when the image can be ordered.

What it protects, and what it does not

It protects data at rest: a powered-off disk, and backups of the disk, against anyone who does not have your passphrase.

It does not protect:

a server that is running and unlocked, against whoever controls the host (its memory or the hypervisor);
a boot chain that was tampered with: the boot partition, the startup image (initramfs) or the firmware;
your own computer, if it is compromised while you type the passphrase.

This version has no failover for an encrypted server, and there is no recovery by Impreza. It is not a guarantee of anonymity or of data integrity.

What you must keep

Keep your passphrase safe yourself. Impreza cannot recover it, and cannot recover your data without it.

There is no recovery key, account reset, support procedure or master key that opens the disk.
If you lose the passphrase, the only way forward is to reinstall the server, which erases everything on it.
Nobody can change or open the disk by telling Impreza that a key was lost.

Before you start

A server installed with the encrypted-disk Ubuntu 24.04 image, which brings the impreza-f68 tool and the cryptsetup-initramfs and dropbear-initramfs packages. The tool refuses anything else:
- the root must be a plain ext4 partition;
- /boot must be its own partition (ext2, ext3, ext4 or vfat). It stays unencrypted, because the server needs it to start;
- at least 512 MiB must be free on /.
Use a freshly installed server. Encryption rewrites every block of the root.
An ssh-ed25519 key pair on your own computer. Only the public key goes onto the server.
One IPv4 network path. You unlock over the network before the disk is mounted. The tool records the server's address, gateway and network card (by its hardware address) for the startup image by itself, and refuses to go on unless the server has exactly one IPv4 default route and exactly one IPv4 address on that card.
To see the encryption state in the client area and the API, the Impreza agent 0.6.41 or later must run on the server, with its encryption report turned on. impreza-f68 prepare-encryption turns it on for this server's own agent, and impreza-f68 enable-reporting and impreza-f68 disable-reporting turn it on or off later; they call impreza-agent f68-policy. Only you, as root on the server, can turn it on: the client area, the API and assistants cannot. A setting copied from another server, or left from before a reinstall, reports nothing. If the server has never reported, the state is UNKNOWN. Turning the report off later does not clear what was reported: a disk once reported encrypted then shows as running with the report off while the server's agent is online, as locked presumed once the agent is silent too, and stays protected. The encryption itself does not use the agent.

Encrypt the disk

Run these as root on the server.

Add your unlock key:
```
impreza-f68 add-unlock-key /root/unlock.pub
```
The file must hold exactly one ssh-ed25519 public key. The key can only unlock the disk; it cannot open a shell. The tool also records the unlock network and rebuilds the startup image.
Prepare the encryption:
```
impreza-f68 prepare-encryption
```
The tool checks the system first and changes nothing if something is missing. It records the network again, in case it changed, turns on the agent's encryption report (if the agent is missing, it warns and goes on), and then prints the unlock host key fingerprint. Write it down. Take a backup first if you want one.
Reboot. The server now waits in its startup image, before the disk is mounted, for 30 minutes. If nobody starts the encryption in that time, it boots normally without encryption, and you can reboot to try again.
Connect and encrypt. From your computer, connect over SSH to the server's address as root with your unlock key. Check the host key against the one you wrote down (see below). Choose a passphrase of at least 12 characters and type it twice. The disk is then encrypted in place, and the server reboots.
- If the connection drops, encryption stops. Reboot and connect again: it resumes with the same passphrase. It does not continue by itself.
- Only one session can encrypt at a time.

Check the result with impreza-f68 status: it shows whether the root is encrypted, whether encryption is still pending, the unlock host key, how many unlock keys are allowed, the unlock network and whether the agent reports the state.

Unlock after every boot

After every boot, including a reboot started by Impreza, the server waits in its startup image until you unlock it. It never unlocks by itself.

Connect over SSH to the server's IP address, as root, with your unlock key.
Type your passphrase. The boot continues.

A wrong passphrase leaves the disk locked, and you can try again. Each attempt is deliberately slow.

This connection reveals your IP address. You connect directly to the server's address, so the server, its network and anyone watching that route can see the address you connect from. Plan for that before you unlock.

Check the server's identity before you type the passphrase.

While the disk is locked, the unlock service answers on the server's address, on port 22 (the standard SSH port, even if you moved the server's own SSH to another port), with a different host key. Keep a separate known-hosts entry for it, for example with your SSH client's UserKnownHostsFile and HostKeyAlias options.
Compare the fingerprint with the one impreza-f68 printed on your own server. The fingerprint the API returns (unlock_host_key_sha256) is only a convenience: it is what the server reported.
A match does not prove the boot chain was clean. The unlock host key lives on the unencrypted /boot, so a copy of the disk can impersonate your server if it can reach your connection.

Never type the passphrase into the provider's web console. Your keystrokes would pass through Impreza, which is outside this promise.

What changes for this server

The state you see is only reported, never proven. The client area, and GET /v1/vps/proxmox/{id}/encrypted-root over the API, show what the agent on your server reports, labelled as not attested. A report counts as recent for two minutes; a report or a contact from the agent dated more than two seconds in the future does not count as recent.

API state	Client area	Meaning
`UNKNOWN`	No encryption report	Nothing has been reported for this server.
`NOT_ENROLLED`	Not enrolled	The server reports, but has not reported an encrypted disk, or not since a confirmed reinstall.
`PENDING_ENCRYPTION`	Enrollment pending	Encryption was prepared but has not finished.
`UNLOCKED_REPORTED`	Enrolled — unlocked reported	The server recently reported an encrypted disk that is unlocked. This is a report, not proof.
`ENCRYPTION_NOT_DETECTED`	Enrolled — running, encryption not detected	An encrypted disk was reported before. The server's agent is online and its recent report does not see an encrypted disk, for example because the server is running from another disk. The server stays protected as encrypted: only a confirmed reinstall, followed by a report without encryption, ends that.
`REPORTING_OFF`	Enrolled — running, report off	An encrypted disk was reported before. The server's agent is online, so the server is running and unlocked, but it is not sending its encryption report: the report was turned off, is refused, or cannot be sent. The server stays protected as encrypted.
`PRESUMED_LOCKED`	Enrolled — locked presumed	An encrypted disk was reported before, and neither a report nor the server's agent has been seen recently. The disk may be locked, or the server may be off, stuck or unreachable: these look the same from outside.

If the client area cannot read the report, it shows Encryption report unavailable; destructive actions stay refused in that case.

In the client area and over the API, destroying the encrypted disk needs the account holder. For a server with a recorded encrypted disk, or with encryption pending, reinstall, restore from backup and rollback to a snapshot destroy the encrypted disk and every byte on it:

In the client area (reinstall and restore from backup), only the account owner, logged in, can confirm. An administrator logged in as you cannot. Type DESTROY ENCRYPTED DATA and acknowledge the permanent data loss. The confirmation is valid for ten minutes, for that server, that action and those exact settings, and it is used up by any attempt: if the request fails, start a new confirmation.
Over the API, only an account API key with the manage scope can confirm. The first request is refused with a warning and a one-time confirmation_token, valid for ten minutes. Repeat the request with encrypted_root_destroy: {"token": "…", "data_loss_ack": true}. The token works once, even if the request then fails, and only for that server and that action. Rollback to a snapshot is offered only over the API.
Over the API, at most five confirmations can be pending for one server; in the client area, at most five per login session.
MCP connections and the AI assistant in the client area cannot destroy an encrypted disk. They are refused even with a token. Any account API key with the manage scope can, including a key paired for an AI client or a command-line tool. Give such a key only to people and tools you would trust to erase this server.
Impreza staff can still reinstall the server from the admin area, and ending the service deletes it. That destroys the disk; it does not open it, because Impreza never has the passphrase.
Creating a snapshot and migrating the server are refused for a server with a recorded encrypted disk, or with encryption pending: a snapshot or migration that captures memory could carry the disk's key.

Limits

The reported state comes from software inside your server and can be wrong, including a report that the disk is unlocked.
A server that is off, stuck or unreachable is not proof that the disk is locked.
Only Ubuntu 24.04 with an ext4 root and a separate /boot is supported.