Other options that I've investigated that involve having a second server:
* A second server with Tang, and Clevis in the initramfs OS
* Keylime
Putting tailscale in the initramfs, and then updating the certs on a frequent enough schedule, seems risky to me. I've already played around with limine enough that I know I don't want to install much in the initramfs...
Realistically for a home server what you are worried about is someone breaking in and selling your drives on Facebook marketplace rather than the FBI raiding your nextcloud server. So TPM automated unlock is perfectly sufficient.
If someone steals the entire machine, the drives will unlock themselves automatically. I don't think it's worth the risk to assume a hypothetical thief is too lazy to check if there's any valuable data on the disks. At the very least, they'll probably check for crypto wallets.
With something like Clevis and Tang, you can set it up so it only auto unlocks while connected to your home network, or do something more complex as needed
E.g. systemd measures basically everything that is part of the boot process (kernel, kernel cli, initrd, ...[1]) into different PCRs, so if any of those are different they result in differen PCR values and won't unlock the boot device (depending on which PCRs you decided to encrypt against). I forgot what excatly it measures, but I remember that some PCRs also get measured during the switch_root operation from initrd -> rootfs which can be used to make something only unlock in the initrd.
If this fails you can always manually input the decryption key and reregister with the TPM. The whole point of this setup is you can't just use a bootable USB to reset the devices password.
You'll be dropped into "enter disk crypt password please" prompt.
Having key off-machine mitigates a lot of that.
> Unless the junkie who stole your server has an unpatched debian login bug,
the key for disk decryption is in memory at that point. There are methods to take it out of it
Of course, a thief could try to bypass the login screen by e.g. booting with a different kernel command line, or a different initramfs. If you want to avoid this vulnerability, TPM unlock can be configured as a very fragile house of cards - the tiniest change and it falls down. The jargon for this is "binding to PCRs"