Clone wiki

KeeCloud / Workflows

KeeCloud is a flexible plugin that gives you lots of options when working with your remote files. Really, KeeCloud doesn't do anything other than open and save remote files with the supported services. It leaves you to configure how to use and sync with those files just as KeePass proper does.


There are several ways that KeeCloud can be used. This is by no means comprehensive either. We'll try to outline several of them here and what the pros and cons are. None of this is really any different than using KeePass over a network share or a URL without the KeeCloud plugin. All KeeCloud does is extend the natural functionality of KeePass to be used with more services. For convenience, we'll got into them a bit here anyway.

Use files directly

One of the ways that KeeCloud can be used is by simply opening the files and using them directly from the service provider and saving them back directly. This is by far the simplest workflow and that is potentially its advantage. However, it works best if you don't use it on multiple machines at the same time. KeePass will detect that it changed while you had it open and prompt you if you want to sync, but you can also overwrite. If overwritten then the last one saved will overwrite the one before it and those changes will be lost. Furthermore, there is a narrow window of time where changes are vulnerable. Admittedly it would only be a problem if two instances with changes were saved at the exact same time and they both slipped past each other's change detection. Not terribly likely, but possible.

Another disadvantage is that the full URL credentials in addition to the password to unlock the database must be used to open the database. The synchronization credential model can't be used.

Sync a local DB with a remote DB

Another way that KeeCloud can be used is to explicitly sync (rather than being prompted on save like above) your local DB with the remote DB. KeePass has a built in synchronization system. This plugin extends this built in functionality to allow new URLs see supported services. The built in synchronization system can merge changes in both directions between two databases. There are many advantages to this model.

This is a better workflow than the above. It is more tolerant of changes by multiple machines for two reasons. The first is that it will open sync and save back changes the remote file much faster than manually modifying the file. This significantly limits the window for conflicting changes. Another reason that this is advantageous is that if two clients do happen to sync at the same time, and changes to the remote file are lost, they still remain in the local copy. The next time that local client is synced the changes can be put back into the file and other clients can pull them later. Everything will eventually replicate to all databases with enough syncing.

With the first model even if you always choose sync, there is a small (admittedly extremely small) window where changes can be lost.

You also have multiple copies of the database. If for some reason corruption does occur, it is unlikely that it will occur in all copies.

A final advantage of this model specific to KeeCloud is that you don't have to enter the full URL access credential every time you want to access the file. You can use a KeePass entry as your URL credential since you will have an unlocked KeePass database for the synchronization process. You just put in the title of the entry in the username field and KeeCloud finds the entry and uses that as your credential instead. See synchronization credentials for more info and detailed instructions.


A more advanced way to employ the synchronization feature above is by using triggers. The official KeePass documentation has a good write up on how to do it so we won't go into it here. Suffice it to say that buttons can be created, or syncing can occur automatically. The sky is the limit. This has all of the advantages of explicit syncing plus any automation or events that you add on top of it.