Open-source project
yogeshpaliyal/KeyPass avatar
yogeshpaliyal/KeyPass

KeyPass: An Android Password Manager That Never Asks for the Internet

KeyPass: Open Source Project & An Offline Password Manager. Store, manage, and take control securely.

787 stars111 forksKotlinMIT

At a glance

What is it?
KeyPass is an MIT licensed Kotlin password manager for Android that ships without the internet permission, stores its vault in a local Room database, and adds an autofill service, TOTP, device credential unlock and encrypted backups. It suits people who want a password manager that cannot phone home.
Who is it for?
KeyPass fits an Android user who wants a password manager whose code and permissions make the offline claim auditable, and who wants autofill and TOTP without handing a server their vault. It is the wrong choice if you rely on sync across devices, since nothing in the documented feature set covers it, and the wrong choice if you want to move to or from other managers, because only importing from Chrome and KeePass is listed while exporting to all three is still unchecked.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 13 days ago.
What is it written in?
Mainly Kotlin, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.

Editorial analysis

The offline claim is a permissions claim

The pitch in the readme is that a modern password manager does not store your credentials on servers, so your passwords are in your hands. What makes that checkable is the first item on the feature list: complete offline, with no internet permission added. That is a stronger statement than a promise about the company's data policy, because an app without the internet permission cannot exfiltrate anything regardless of what the code intends. The topic tags point the same way, with offline behaviour, the open-source nature of the code and the password generator as separate concerns. The licence is MIT and the code is accessible to everyone, so the two halves of the claim, no network access and readable source, are both verifiable by a reader with a decompiler and an app manifest.

What the vault is built on

The stack list is short and modern Android. Kotlin is the language, Material Design 3 supplies the interface, and the architecture is MVI with LiveData and MutableLiveData for state. Storage is a Room database, preferences are held in Jetpack Data Store, and Hilt handles dependency injection. The cipher library is used for backup encryption and decryption, which is the one place encryption is explicitly named. Two directory names in the repository, common/ and shared/, suggest the code is split so that a portion is reusable, and a desktop/ directory sits alongside app/, which is the more unusual thing here and is covered below. The screen is Jetpack Compose, which is the modern replacement for the View system, and the whole thing is set up for a build with Gradle in Kotlin DSL, with a buildSrc/ directory for the build logic.

Autofill, TOTP and unlocking with device credentials

The three features that decide whether a password manager is usable day to day are present. There is an autofill service, so the app participates in the system autofill flow rather than making you copy and paste. There is TOTP, which means the one-time codes for two-factor accounts are generated in the same place as the passwords. And the app authenticates with device credentials, covering PIN, pattern and biometrics, so the vault is not protected by a password you have to invent and remember. Alongside those, screenshot blocking prevents the app's contents from appearing in the recent-apps thumbnail, which is a small thing that matters on a phone you hand to someone. Dark mode support and Material Design 3 handle the appearance, and auto backup covers the case where you lose the device.

Encrypted backup, restore and a warning to read first

Encrypted backup and restore is on the feature list, and the backup file is encrypted with the cipher library rather than stored in the clear, which is the whole point of backing up a vault. There is also a disclaimer in the readme that says to take a backup before updating to the new app, and that deserves to be taken literally rather than skimmed. It implies that at least one update path has had a migration that could lose data, and the project is telling users to protect themselves before taking the risk. The readme also carries a warning that the project is looking for a new name, with a discussion thread for suggestions, which is a small but telling sign of where the maintainer sees the project going.

Import works one way and export does not work yet

The import and export lists are the most honest part of the feature list. Import is done from Google Chrome CSV and KeePass CSV, and Bitwarden import is still an unchecked box. Export is more limited still: Google Chrome, KeePass and Bitwarden are all unchecked, so there is no documented way to move your vault out of KeyPass. That asymmetry is the practical limitation of the project today. A password manager you cannot export from is a lock-in risk of a specific kind, and the usual reason is that the export format has to be lossless and the maintainers would rather ship a correct importer than an incorrect exporter. If you are migrating in, the Chrome and KeePass CSV imports are there. If you might migrate out later, the export boxes are the thing to watch.

How the project is built and where the code lives

The prerequisites table names Android Studio at Ladybug Feature Drop 2024.2.2 and Java 17, and the repository holds the usual Android project files: an app/ module, a baselineprofile/ directory for macrobenchmark baselines, build.gradle.kts and settings.gradle.kts, a gradle/ directory with the wrapper, and gradlew plus gradlew.bat. There is a fastlane/ directory holding the store metadata and the phone screenshots the readme embeds, a scripts/ directory, a githooks/ directory, a renovate.json for dependency updates, and a whatsnew/ directory for release notes content. A keystores/ directory is present for signing configuration, and the LICENSE file carries the MIT text with a 2021 copyright to Yogesh Choudhary Paliyal, who is also the named author with a Twitter handle, an email address and several donation links.

Distribution, translations and the desktop directory

The app ships through three stores: Google Play, F-Droid under the package name com.yogeshpaliyal.keypass, and the Indus Appstore. The F-Droid listing matters more than usual for a password manager, because it is a channel that does not require a Google account and does not need the Play services, which matches the offline design. There is also a master build artifact linked from the readme as a free debug apk, described as a sample app build, which is the usual way to let people try a build before going through a store. The repository has a README_ja.md for Japanese, and the translation status badge points at a Weblate project, so translations are handled through a hosted service rather than through pull requests on the repository. The desktop/ directory is the odd one out: a password manager with a desktop target, and it is the piece to watch if you are not sure whether this is an Android-only tool.

Contributing, the development lifecycle and what to check before installing

The contribution flow is a standard fork and pull request, with one instruction that is worth repeating: open an issue first to discuss what you would like to change. The steps then are to fork the project, create a feature branch, commit, push the branch and open a pull request.

bash
git checkout -b feature/amazing-feature
git commit -m 'Add some amazing feature'
git push origin feature/amazing-feature

The last instruction is to make sure the tests are updated as appropriate. Development dependencies are named in the prerequisites table, and the release history shows a staging build tagged latest-master on 2026-07-18 alongside versioned releases v1.4.42 and v1.4.41 from 2025-09-03, with the last push on 2026-10-10. That pattern, a rolling staging tag next to a versioned line, tells you to expect the store build and the master branch to differ. There is a SECURITY.md, a code of conduct, and a featured.md file recording where the project has been written about, and the open question for an adopter is the export question from earlier rather than the feature list.

Editorial conclusion

KeyPass fits an Android user who wants a password manager whose code and permissions make the offline claim auditable, and who wants autofill and TOTP without handing a server their vault. It is the wrong choice if you rely on sync across devices, since nothing in the documented feature set covers it, and the wrong choice if you want to move to or from other managers, because only importing from Chrome and KeePass is listed while exporting to all three is still unchecked. Before you install, read the backup warning in the readme and export an encrypted backup before updating.

Frequently asked questions

Does KeyPass need internet access?

No. The first feature is complete offline, and no internet permission has been added to the app, so the vault never leaves the device through the app itself.

What can KeyPass import from, and can it export?

Import works from Google Chrome CSV and KeePass CSV, with Bitwarden import still unchecked. Export to Google Chrome, KeePass and Bitwarden are all unchecked, so there is no documented export path yet.

What technology does KeyPass use to store and protect the vault?

Kotlin with MVI architecture and LiveData, a Room database for storage, Jetpack Data Store for preferences, Hilt for dependency injection, Material Design 3 with Jetpack Compose for the interface, and the cipher library for backup encryption and decryption.

Does KeyPass support autofill and two-factor codes?

Yes. The feature list includes an autofill service and TOTP, plus authentication with device credentials covering PIN, pattern and biometrics, and screenshot blocking to keep the app out of recent-app thumbnails.

What should I do before updating KeyPass?

Take a backup first. The readme carries an explicit disclaimer asking users to back up before updating to the new app, and encrypted backup and restore is a supported feature.

Official sources

  1. License: MIT
  2. Project website
  3. README
  4. Releases
  5. yogeshpaliyal/KeyPass on GitHub
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/yogeshpaliyal-keypass.svg)](https://hysenlabs.com/projects/yogeshpaliyal-keypass)

Was this useful?