These days with LXD supporting offline storage pools, I think a better approach may be to use an encrypted disk image (LUKS) and then feed that block device (/dev/mapper/some-name) to LXD to put a ZFS or other storage pool on top of it.
This means that the LXD database and images will be on the root partition in /var/snap/lxd/common/lxd but all actual instance data will be on the encrypted storage.
On boot, LXD will be able to startup normally, will detect it’s lacking its storage pool and will hold instance startup. Then when you want to access your instances, you tell LUKS to setup the /dev/mapper device, LXD will detect it and will bring your instances up.
Putting all of /var/snap/lxd/common/lxd on encrypted storage that’s not available on startup is certainly possible but will need more interactions with systemd and the host OS than the approach I just described.
That’s exactly what I’m doing. I’m just trying to create an extra guard gate scene for my application so that my instances cannot be read the information (info, programs, etc). If the implementation is not as simple as you say then I will continue with the current solution.