KeeAnywhere: cloud storage backends for the KeePass password database

One database file, eight places to keep it

KeeAnywhere is a plugin for KeePass Password Safe that provides access to cloud storage providers, the cloud drives. The stated goal is to offer a simple UI while integrating deeply into KeePass, and the README says that covers all kinds of users, novices, experienced ones and power users.

The problem it solves is narrow and real. KeePass keeps its database in a local file, and a local file is awkward if you use the same password manager on a desktop at work and a laptop at home. Syncing that file by hand means choosing a sync tool, and every sync tool has its own opinions about conflict resolution, file locking and partial writes. KeeAnywhere sidesteps that by letting the cloud provider be the thing that holds the single file.

The supported providers are listed in alphabetical order, and there are eight of them: Amazon AWS S3, Azure for both Blob and File storage, Box, Dropbox, Google Drive, Google Cloud Storage, HiDrive and OneDrive. That is a deliberate mix. The consumer services, Google Drive, Dropbox, OneDrive and Box, cover the ordinary case where a person already has an account. The infrastructure services, S3, Azure, Google Cloud Storage and HiDrive, cover the case where the database should live in a bucket you control rather than in a consumer account, and Azure appears twice because the plugin handles both its Blob and its File storage products.

The plugin is written in C#, published under the MIT licence, and the project homepage is keeanywhere.de with its own documentation, installation guide and a page of known issues. There is also a Chocolatey package, `keepass-plugin-keeanywhere`, so installation does not require hand assembly of the plugin files.

Building the plugin on Windows from a batch script

The build instructions in the README are short. You run build.cmd and see the output in the folder build, with further details in BUILD.md.

The command is build.cmd, and the output lands in a folder named build. That is the whole documented build step, and the repository layout explains why it can be that short. There is a `KeeAnywhere.sln` at the root for the solution, a `KeeAnywhere/` directory for the plugin project itself, a `lib/` directory for the dependencies it links against, a `chocolatey/` directory holding the packaging for the Chocolatey package, and `doc/` alongside `docs/` for documentation. The `nuget.exe` file sitting at the root and the `NuGet.config` next to it mean the build pulls its packages through NuGet rather than through a package reference inside the project file.

Two files are worth understanding on their own. `version_manifest.txt` is presumably where the version is recorded for the packaging step, since the same repository ships a Chocolatey package that needs a version. And `CHANGELOG.md` at the root is the release history, which is the place to look before upgrading.

The `lib/` directory deserves a note, because it is where the compatibility constraint comes from. A KeePass plugin is not a standalone application. It is a library loaded into the KeePass process, and it has to match the plugin API of the KeePass version it is running in. Vendoring those libraries in the repository is what lets the plugin target a specific API version, and it is also what pins the plugin to that version of the API rather than the latest one.

The build is a Windows batch script, so building the plugin from source is a Windows-only operation as documented, even though the project itself is MIT licensed and open.

A release history that has not moved in a while

The listed releases tell you the state of the project without needing to read the source.

v2.1.0 was published on 2024-06-17. Before that, v2.0.3 and v2.0.2 were both published on 2021-05-21, the second roughly five and a half hours after the first. That pattern is a single maintenance session in 2021 followed by a major step to 2.1.0 three years later.

The last push was on 2026-05-08, and the repository is not archived. So there has been work on the repository since the last release, but the release tag and the working tree are not the same thing here. If you install the plugin, you are installing the 2.1.0 artefact from the GitHub releases or the Chocolatey package, not whatever is on the master branch. For a plugin that sits inside a password manager, that is the difference that matters: you want a released build you can verify, not a source snapshot.

The version history also tells you about the plugin's shape. A 2.0 line followed by a 2.1 line suggests a major rewrite in the 2.0 series, most likely to move to a newer KeePass plugin API, and the small patch releases in 2021 for the 2.0.3 and 2.0.2 pair suggest an adjustment to a new KeePass release or a dependency update rather than new functionality.

The project's own documentation includes a Known Issues page, and for a plugin that talks to eight different cloud APIs on a password manager's database, that page is likely to be the most useful part of the site for anyone about to try it.

Why the provider list is fixed at build time

The eight supported providers are named in the README as a list, and there is no configuration file or setting described that would let a user add one. That is a design consequence rather than an oversight, and it is worth understanding before you pick a provider.

Each provider needs an implementation of the same operations: authenticate, list files, read, write, and handle the fact that another process might have the file open. The provider SDKs differ in all of those, and a cloud API that cannot lock a file is a different problem from one that can. Compiling the list in means the plugin knows exactly which of those guarantees it can rely on for each backend, and the work is done once rather than at runtime.

The cost is the one that matters for adoption. If your cloud provider is not among the eight, there is no way to add it without writing the code yourself and rebuilding the plugin. For a KeePass user, the practical effect is that the choice of where the database lives is made for you, and the criteria are the eight names in the list rather than your preference.

The project also carries a Privacy page on its website and a DONATE.md file in the repository, along with a contribution page. The privacy page is worth reading before you point a plugin at a consumer cloud account, since the plugin's whole job is to move an encrypted database between a local machine and a hosted drive. The database contents are encrypted by KeePass itself, so what the provider sees is a file, but the metadata around it, the name, the size, the modification time and the request pattern, is visible to whoever runs that service.

There is also a `doc/` directory and a `docs/` directory side by side in the repository, which suggests the site content and the in-repository documentation are maintained separately.

Against a sync tool and against per-device databases

The comparison worth making is with the two alternatives to a plugin like this.

The first is a file sync tool, Dropbox or OneDrive's own sync client or a cloud drive's sync folder, with the KeePass database inside it. The advantage is that this already works with every KeePass version and every provider, and it needs no plugin at all. The disadvantages are the ones the plugin is built around. The sync client may keep a cached copy on disk, so a change made on one machine can be overwritten by another before it syncs, and two machines editing at once produce a conflict file rather than a merged database. The database is also present on disk in a synced folder, which is one more copy of a file worth protecting.

The second is per-device databases. Each machine has its own database, kept in sync by hand or left separate. This is the safest option in one specific way, because there is no shared file to corrupt, and it is what many KeePass users do. The cost is that the two databases drift apart, so a password changed on one is not changed on the other, and there is no single list of what you actually use.

KeeAnywhere sits between the two. The database is one file in a cloud account, so there is one authoritative copy and one password change to make, and the provider handles the transfer rather than a sync client guessing at conflicts. The remaining risk is the provider's own behaviour on concurrent access, which is a different and generally better documented problem than sync conflicts, and it is the kind of thing the Known Issues page would cover.

The other comparison, with commercial password managers, is not close. KeePass stores an encrypted local file with no account and no server. Adding a plugin that talks to a cloud account keeps that property, which is the main reason someone would use this rather than a hosted password manager with built-in sync.

Editorial conclusion

Adopt KeeAnywhere if you run KeePass on several machines and want one database in a cloud drive rather than a file you sync by hand, and check that the provider you need is in the list of eight, since adding one means a code change and a rebuild. Do not adopt it if you need a provider that is not compiled in or if you are on a KeePass release newer than the one the plugin targets, and verify that your chosen drive works with the plugin's file locking before you move a database you rely on into it.

Frequently asked questions

Official sources

1. Kyrodan/KeeAnywhere on GitHub
2. License: MIT
3. Project website
4. README
5. Releases