You want to make it harder for the hoster’s employees to casually view your
data on disk.

You trust your hoster now, but you want to have an easy way to cut off their
access to your data – maybe when they change owners, or when you anticipate
that they are forced by some authority to grant access to your data.

You want your data to be safe in case the hosters disks get confiscated,
stolen, or discarded without shredding.

You don’t trust your hoster, or you fear that they may be forced to grant
access to your data without a timely warning. If your hoster or a powerful
third party really wants to view your data, they could

install a modified version of CryptOps that doesn’t really encrypt;

man-in-the-middle your first ssh connection to the server running in the
initrd, capturing your encryption password when you first enter it;

access your decrypted data in memory while your VPS is active;

various other methods.

It is very hard to prevent someone who has access (physical or via network) to
the host running your VPS from reading your data, and CryptOps does not pretend
to do so.

It increases the chance of data loss: if you forget or lose your encryption
password, a single reboot of your VPS (for whatever reason) renders your data
irrecoverably lost.

It can increase downtime of your VPS: whenever your VPS reboots, you need to
become aware of this (though we have a customisable hook to notify you of this
situation), connect to the VPS, and enter your encryption password; only then
can the boot process of the VPS continue. All this time the service provided
by your VPS is not running.

You may not need full disk encryption of your VPS: depending on the software
running on your VPS, it could be easier to encrypt only some data directories.
On the other hand, it is easy to overlook some sensitive data stored in
configuration, cache files, temporary files, etc.

The default CryptOps setup includes a small partition that contains unencrypted
data needed by the CryptOps initrd. This data contains the SSH public keys that
are used to authorise users logging into the Dropbear shell.

Note that these can be coupled to private keys on your computer, so in a sense
can be seen as identifying material. To be secure, at least always:

Keep your private keys private! This is very important. They are essential
for the security of your VPS

Think about what you enter as an identifier for your public key. The public
key is formatted as follows: <key-type><public-key><identifier>. The
identifier will often default to your (user)name, but can be anything. If you
want to maximise anonymity, use something that you can use to identify the
key, but does not directly identify you.

Other than some laptops with full disk encryption, CryptOps does not offer an
encrypted boot partition. This is because booting a virtual machine is slightly
different from booting a laptop. Often the initrd and kernel will be provided by
the hosting provider.