I’m trying to say that that vector is much easier to abuse for the hardware owner, so be aware of your mitigations for it too if you want to go down this route. There are some things you can do to mitigate that, although I think if you’re using a general purpose Linux distro like NixOS you’re probably not mitigating it.
That said, even if you only booted your server a single time on Hetzner hardware, and then turned it off forever, disk encryption is easily broken by someone with full control over your hardware.
The problem is that your host cannot magically start an encrypted binary. Something must decrypt your drives first.
The way this is done in the Linux world is that you have a stage 1 with an “initial ram disk”, which is just a snapshot of a running kernel with an init script that knows how to decrypt your partitions. This can provide what you’re looking for if you can be sure that this initial ram disk is never tampered with - if you cannot, any initial ram disk can be inserted, and once you type in your decryption password this initial ram disk can do whatever it wants with your files and encryption key. On every boot, Hetzner could collect your password and store it.
There is a mitigation for this, albeit one not supported on NixOS (yet). With UEFI Microsoft introduced secure boot, which uses the motherboard firmware to check if the booted binary is signed by a key that you can install. This works somewhat well in consumer hardware, where you can kind of trust the motherboard manufacturer to not be malicious, and their firmware to not be blatantly buggy or backdoored (well, maybe). However, for a server provider like Hetzner this is almost useless since they control all the hardware including the motherboard fully.
I suppose this might protect you from a rogue employee who isn’t performing a premeditated attack and doesn’t have access to monitoring equipment (since it involves capturing your password while you reboot the system, which may be rare), but ultimately if you do not trust Hetzner with this data you probably shouldn’t be hosting there in the first place. It’s too easy to bypass basic disk encryption for them; whether by inspecting the running system, adding malicious devices or tampering with something to exfiltrate your password on boot.
This may match your threat model, I’m just pointing out that this may only give you a false sense of security. Still going down this path because it’s kind of cool to play with and might give you some protection is not an issue, of course, but there is a big caveat that you should not at all trust it 