I’m looking into setting up a self-hosted NextCloud, and back it up to an external storage (Dropbox, S3...). I want this backup to be encrypted.

Fortunately, that is supported natively by NextCloud. All I have to do is make sure that the private keys are backed up as well in case I need to restore.

Now, I would very much like to store those encryption keys at the same location I store the encrypted backup.

Of course that would defeat the encryption. Unless the private keys themselves are encrypted with a password, in which case my backup is “password encrypted”, which is good enough for my use case.

But I couldn’t find a definite answer to that question in NextCloud manual.

tldr: are NextCloud encryption keys password protected?

Also, am I missing something else worth noting?

1 Answer 1


The answer to your question is technically "yes", but there are some noteworthy implications to consider specific to the use case of backups.

There are two main server side encryption schemes in Nextcloud. Recent versions of Nextcloud use a "master key" by default, which can decrypt everything.

There is also an alternate implementation of encryption based on per-user keys, which applies to older set ups, or people who disabled master key encryption manually.

If you see something like this, it's using the per-user (old) style:

Here is a description from one of the authors of the Nextcloud Default Encryption Module plugin:

In general Nextcloud provides to possible setups:

  1. Every user has it’s own private/public key and the Admin can additionally offer a recovery key which each user need to accept (opt-in). In order to decrypt the user files with occ you need either the users password and in this case the users private key + the file keys + the database to check the signature or the recovery key password (if the user enabled the recovery key). In case of the recovery key you need the private recovery key, the password of the recovery key, the file keys and the database. This was the default setup until Nextcloud 13, you could enable the master key with occ encryption:enable-master-key, in this case setup 2 is used.

  2. A master key is used. This is the default if encryption was enabled for the first time with Nextcloud 13 or later or if it was enabled by the admin with the occ command occ encryption:enable-master-key. In this case there is only one key used for all files of all users, the private key is encrypted with the instance password. In order to decrypt all files with the occ command you only need the private master key, the file key and the database.

For the per-user method of encryption (old style), the keys are protected by the Nextcloud user's login password:

Nextcloud’s server-side encryption generates a strong encryption key, which is unlocked by user’s passwords. Your users don’t need to track an extra password, but simply log in as they normally do. It encrypts only the contents of files, and not filenames and directory structures.

(See Encryption configuration — Nextcloud latest Administration Manual latest documentation).

For the master key implementation (which is the current default and most likely what you'll use), the absolute minimum needed to have a chance at decrypting the data is 1) the master key pair, and 2) a secret from config.php. To follow the official process (i.e. to ensure success), you also want a dump of the database from after the files were encrypted. You can attempt to break the encryption without the database by disabling file signature checks, but your mileage will vary.

So yes, you can put the keys in plain text along with the encrypted backup in something like Dropbox with relative safety. Without the secret from config.php, it's unlikely that an attacker would be able to decrypt the data. This also means that you won't be able to. If you have the keys and the config.php secret, but the database is encrypted, you're stuck with attempting to break the encryption by disabling signature checks. For a smooth recovery you'll want the master key, config.php file, and an up-to-date database snapshot, all saved securely somewhere else.

At this point, I think the convenience factor of keeping the keys with the backup is negated. Another annoyance would be the restore process. You'd still be spinning up a new Nextcloud instance to decrypt the data. The decrypted data would then be a full backup of your Nextcloud instance, which would itself need to be imported/restored to a Nextcloud instance.

Using another approach, like this one, might make your life easier in the event that you do need to restore from a backup after a total loss:


There are plenty of similar examples for backups like this posted online. The key points are:

  • A full backup is taken, a single snapshot that can be used to easily rebuild following the official documentation
  • The backup is compressed into a single file which is easier to transfer and encrypt
  • The encryption concern is decoupled from Nextcloud itself. You can choose any method that suits your needs, using standard tools like GPG
  • Encrypted backups are stored at some remote destination which supports API interactions via CLI, such as S3 or B2
  • The whole process is just a script - automate it with cron, and run it manually whenever you want
  • Adding another backup source is low-friction - just write another step in the script to also copy the file somewhere else
  • To restore, all you need to do is fetch the latest backup, decrypt it (with standard tools that you chose), copy it to the right place on a new instance, and follow the official guides (even easier for snap installs)

Hope this helps! Encryption in Nextcloud is deceptively easy to set up, but it definitely comes with risks and trade-offs. There's no shortage of forum posts and GitHub issues with tales of lost data using Nextcloud encryption.

I've been using Nextcloud as the main driver of an "I don't need Google" set up for a couple of years now. It's been shockingly low-maintenance, very reliable, and rewarding to customize. I hope you give it a try!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .