Monica Pass, a local-first Android vault that speaks Bitwarden and KeePass

One vault for two password ecosystems

Monica is described as a local-first password vault that aggregates Bitwarden and KeePass, and the README is precise about who that is for. The first audience is someone who wants local-first password management and does not want their account data hosted on a third-party cloud. The second is someone who already uses Bitwarden and also maintains KeePass data in .kdbx files, which is a common situation in organisations that migrated from a desktop password manager to a service and never cleaned up. The third is someone who needs autofill in the Android application and in a mobile browser. What the app stores locally is an encrypted vault of logins, bank cards, identity information, private notes and attachments. The aggregation is real rather than cosmetic, since the Android side contains both the Bitwarden API and sync capability and the KeePass read and write capability, and the built-in TOTP generator keeps second factor codes in the same application as the passwords they protect.

Installing means an APK and a master password

There is no package manager entry in the documentation, and the install path is deliberately short. You download the latest APK from the Releases page, install it on a device running Android 8.0 or later, and initialise the master password. The master password is therefore the anchor of the whole system, because it is what unlocks the local vault and what derives the encryption key. The documentation site is at monica-pass.github.io/MonicaDocs, and the project publishes its release notes in the repository as a separate Markdown file for Android releases. The release history shows a steady sequence of versioned builds, with V1.0.318 on 2026-10-08 and V1.0.319 on 2026-10-13, and there is also a channel published as a development preview build, which is a separate tag rather than a stable version. The last push to the repository was on 2026-10-17, so the project is being worked on continuously.

The Android stack behind the vault

The implementation notes in the README name the professional edition's stack in detail, and it is a conventional modern Android setup. The user interface is Jetpack Compose with Material 3 and Navigation Compose. The data layer is Room, with a PasswordDatabase, DAO and Repository, and the concurrency model is Kotlin Coroutines with Flow. Dependency injection is Koin, and the application class is MonicaApplication. Security is built on the Android Keystore, EncryptedSharedPreferences and BiometricPrompt, which is what gives the biometric unlock and the encrypted local settings. Background work is WorkManager, with an AutoBackupWorker responsible for automatic WebDAV backup, so the backup is scheduled by the system rather than by a foreground service. The protocol libraries are the interesting part for anyone integrating it, with Retrofit and OkHttp for the Bitwarden API, kotpass for KeePass, and sardine-android for WebDAV.

The security model in four lines

The README states the cryptographic choices directly. Encryption is AES-256-GCM, which is authenticated encryption, so a modified ciphertext fails to decrypt rather than producing garbage. Key derivation is PBKDF2-HMAC-SHA256 with a high iteration count, which is the standard way to turn a human-chosen master password into a key that resists offline guessing. The master password hash and the secure configuration are managed by a local security component, and the biometric unlock is provided by the system rather than by the app re-implementing it. The last point is about network exposure, and it is narrow. The application declares the network permission, and the README says the reason is the online capabilities, the Bitwarden integration and the WebDAV backup and sync. So a deployment that never connects to Bitwarden and never syncs is still an application with the network permission granted, and a reviewer checking permissions should read that sentence rather than assume the local-first label means no network access.

MDBX is a vault format, not a password table

The most substantial engineering in the repository is a new local-first encrypted vault format called MDBX, and the documentation is unusually open about its state. The README says MDBX is the format Monica is advancing, that it is not a simple password table, and that it is designed around nested folders, attachments, commit history, conflict detection, a tombstone deletion chain, snapshot restore and a Tiga security mode. The point about commit history and tombstones is the one that matters for a sync system, since a deletion that has to survive on two devices needs a record that says it happened, and a conflict has to be detected rather than silently resolved by last write. The project publishes a storage compatibility contract for cross-client development and for AI tooling, a workspace description in mdbx/README.md, a client integration guide, and the full format specification under mdbx/docs. If you are writing another client against this vault, those documents are the entry point, and the fact that a contract document exists at all is a sign the format is still moving.

Sync is optional, and it goes to your own WebDAV

The sync and backup story is deliberately unglamorous. The README lists optional sync and backup through your own WebDAV infrastructure for moving data between devices, and the app accesses it with sardine-android, with the AutoBackupWorker in WorkManager handling the automatic part. Nothing here depends on a hosted service, which is consistent with the local-first premise and is the reason a WebDAV endpoint is mentioned at all. The Bitwarden side is the opposite, since that path is a connection to someone else's API, and it is where the network permission is actually used. The practical implication for an adopter is that the trust boundary moves: a WebDAV backup puts your encrypted vault on infrastructure you operate, while the Bitwarden integration puts credentials in a service you do not. The README also notes that a TOTP code and the password it protects live in the same application, which is convenient and also means one compromise reaches both.

Passkeys on HyperOS, GPL, and a project funded by donations

The known limitations section names one device family, and it is worth knowing before you recommend the app. Because of system compatibility reasons, Monica for Android currently cannot create passkeys on some Xiaomi HyperOS devices, and the README points at a third party module, HyperMonica, that attempts to work around it. That is a good example of a limitation documented honestly, and it also tells you where the project stands on the newest credential technology. The licence is GPL-3.0, so a modified build carries the same obligation. The funding model is visible in the README, with badges for Afdian, Ko-fi, PayPal and Liberapay, and the stated priorities for the money are security audits and hardening of the cryptographic scheme, Android experience and stability work, and unifying cross-platform features with documentation maintenance. The repository itself is organised with the Android application under its own directory, the documentation site under MonicaDocs, the MDBX material under mdbx, and the README translated into Chinese, English, Japanese, Vietnamese and Russian, plus a directory of alternate language easter eggs.

Editorial conclusion

Monica Pass fits a person who wants their credentials on their own device rather than in a vendor account, and who has both Bitwarden and KeePass data to reconcile, since the app reads and writes .kdbx files and talks to the Bitwarden API from the same vault. It does not fit a user whose passkey workflow depends on Xiaomi HyperOS devices, because the documentation says passkey creation does not work on some of them, and it does not fit a team that needs the vault format to be an industry standard, since MDBX is a format this project is still developing. Verify three things first: the Android version, since the minimum is 8.0, the interoperability of the MDBX vault with your other clients, because the storage contract document exists precisely because that is not settled, and whether the WebDAV endpoint you would back up to is one you control.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Monica-Pass/Monica on GitHub
3. Project website
4. README
5. Releases