Rowel: a local-first secrets manager where the vault is encrypted files on your disk

A vault is encrypted files, not a service

The pitch in one line from the README is that Rowel keeps every password, passkey, card, ID, SSH key and .env file in one encrypted vault on your own devices, with no account, no server and no subscription. The first of the nine reasons given for the project makes the architectural point: your vault is encrypted files on your own disk and it works fully offline, so there is nothing to sign up for and no server that could be breached.

That is a different security posture from the hosted model, and it is a deliberate one. The author states the motivation plainly, that basic personal security should be available to everyone for free and that nobody should have to pay a monthly subscription to keep their passwords encrypted and safe. The plan is that Rowel stays free and open source for personal and family use, with a possible paid option for professional teams later that will not take anything away from the free app.

The implementation is a Tauri 2 application, with the Rust side in src-tauri/ and the interface in src/ as a Vite and TypeScript project, and the topics list both tauri and tauri2 alongside the platform names. It runs on macOS, Windows, Linux and iOS, with the iOS build distributed through TestFlight while it is in beta.

SSH keys, API keys and .env files as item types

The second reason given is that Rowel is built for developers, and the specific claim is that SSH keys, API keys with environment and scopes, and whole .env files are their own item types rather than notes you have pasted in.

That distinction has consequences for how the vault behaves. An .env file stored as a structured item can be listed and searched without its values being exposed, because the third reason states that the vault is encrypted on disk and each item is sealed a second time inside it, the list and search work without unsealing anything, and the interface receives an item's secrets only when you open that item. SSH keys are supported with fingerprint randomart and Ed25519 keys generated in the application, so the key pair never has to travel through a chat window or a password manager's notes field.

Items arrive in two ways. You can import an export from your previous password manager or browser, or you can add your first login, card or SSH key by hand. The import list is specific and worth checking against your own setup before you commit: 1Password, LastPass, Bitwarden, KeePass through a CSV export, Enpass, Chrome, Safari, and any FIDO CXF export. The README also says that the import produces a report for anything it could not import, which is the detail to look for afterwards, since a silent gap in an import is the failure mode that matters here.

Lockboxes, per-item sealing and merge without dialogs

One vault with one master password can be divided into lockboxes such as Personal, Work or Clients, and each lockbox is kept in its own encrypted file and can sync to its own cloud account. That gives a single master secret to remember while still keeping separate encrypted artefacts per area of life.

Sync is bring your own cloud. Each lockbox syncs to Google Drive, Dropbox or iCloud as one encrypted file, and the README states that Rowel can only reach its own app-scoped storage there, so the cloud provider stores ciphertext it cannot read. Conflict handling is the part that sets this apart from most vaults: edits from different devices merge item by item on their own, there are no conflict dialogs, and when two devices change the same item the newer edit wins.

That last rule is worth thinking about before you rely on it. It removes an entire category of friction, the dialog that asks which version to keep, but it also means a change made on one device can silently overwrite a change made on another for the same item. Nothing is lost at the item level, since whole items merge, but two edits to the same secret within the sync window resolve by timestamp rather than by asking.

On iOS, iCloud is offered on iPhone and on Mac builds whose signature carries Apple's iCloud entitlement, which is a distribution detail rather than a user setting.

Sharing by expiring link, and reading cards on the device

Two features handle the situations where a password manager usually becomes awkward.

The first is private sharing by link. One item can be shared through an encrypted link that expires in 24 hours and can be revoked, and the key lives only in the link. Sharing works from a lockbox synced to Google Drive, and the recipient opens the link in Rowel. The consequence is that a shared secret is not protected by your master password at the other end, so the expiry and the revocation are the only controls, and the recipient needs Rowel to open it.

The second is scan to fill. You take a photo of a card or a passport and Rowel reads it on your device to fill in the fields, with nothing uploaded, and it is available on macOS, Windows and iOS. Reading a document locally avoids sending an identity document to an OCR service, which for a card number and an expiry date is the difference you would want, and it is one of the more credible local-first claims in the list because the alternative is fairly well understood.

A third item, releases you can verify, says that every installer comes with proof of how it was built and that the macOS app is signed. On desktop the app updates itself afterwards, and it only installs updates whose signature checks out.

Installing on each platform, and getting it with the GitHub CLI

Installation is a download rather than a package manager step, and the README notes that the download names carry no version in them so they always resolve to the newest release. macOS has a universal .dmg, Windows has a setup .exe, and Linux has a .deb, an .rpm and an .AppImage. iOS has no file to download, since it comes from Apple through TestFlight for as long as it is in beta. Until the version-free names are in place, the README points at the versioned installer on the releases page, which stays there alongside the version-free copy.

The GitHub CLI route is a single command, and the pattern selects the installer for your operating system:

gh release download --repo fwdai/rowel --pattern 'Rowel_universal.dmg'   # macOS; use Rowel_x64-setup.exe (Windows), Rowel_amd64.deb, Rowel_x86_64.rpm or Rowel_amd64.AppImage (Linux)

After the install, getting started is four steps. Open Rowel and choose Start fresh, or Continue with a cloud account if you already use Rowel on another device, or on desktop Restore from a backup file with the .rowel extension. Choose a master password and type it again, after which you can turn on Touch ID, Face ID or Windows Hello on supported devices. Bring your items in through Settings and Import, or add one by hand. The last step is optional: connect Google Drive or Dropbox in Settings to keep devices in sync.

The design point worth noticing is the ordering. Start fresh and the vault is created locally with no network call at all, and the cloud connection is an explicit later choice.

Building from source with Tauri and compile-time OAuth keys

The repository is a Tauri project with a Rust side under src-tauri/ and a TypeScript front end under src/, built with Vite, with the package scripts driving the whole workflow:

"dev": "vite",
"build": "tsc && vite build",
"test": "vitest run",
"test:e2e": "wdio run tests/e2e/wdio.conf.ts",
"tauri:dev": "tauri dev",
"tauri:build": "tauri build",
"ios:init": "tauri ios init"

The extension has its own set of scripts for install, build, lint, test, icons, strings, sync and theme checks, which tells you the browser extension is a first-class part of the project rather than an afterthought, and the README links a browser extension document alongside the threat model and the security policy.

The configuration detail that will bite a builder is in .env.example. The Google Drive OAuth client id and secret are baked into the binary at compile time, the Dropbox app key is read at run time or baked in, and the Google API key used for receiving shared secrets is also baked in at compile time. The file is explicit that the real .env is gitignored and never committed, and that in continuous integration the same values come from repository secrets. The instructions for a plain local run are:

set -a; source .env; set +a; bun run tauri dev

Leaving the Google OAuth client id empty builds a binary without Drive sync configured, and leaving the Google API key empty builds with receiving disabled. So a local build without any credentials produces a working local vault and a silent absence of the cloud features.

Where Rowel is not the right tool

The limits come from the local-first premise and from the current state of the project.

There is no shared vault with roles, no service accounts and no team policy in the current product. The README frames professional teams as a possible future paid tier rather than an existing feature, so if your requirement is a credential store that a whole engineering org can use, Rowel is not that today.

Second, the sharing model is narrow. A shared item needs a lockbox synced to Google Drive, it is delivered as a link with the key inside it, it expires after 24 hours, and the recipient needs Rowel installed to open it. For sending a secret to a colleague once, that is workable but heavier than a chat message, and for sending one to many people it does not apply at all.

Third, the version is 1.0.x and the releases are days old. v1.0.1 and v1.0.2 landed on 2026-10-13 and v1.0.3 on 2026-10-15, so the 1.0 line is barely established, and a 1.0 version number does not tell you the format will never change. The README does not document a vault format migration guarantee, and the backup route is a .rowel file, so keeping an export outside the app is the only way to be sure.

Fourth, GPL-3.0 is a condition you need to accept. The repository is licensed GPL-3.0, and distributing a modified build of a desktop application under those terms has consequences you should read in the LICENSE file rather than infer. That is not legal advice, it is the reason to read it.

Against a browser password manager

The realistic alternative for most people is the password manager already built into the browser, or the one they already pay for, and the comparison is not one-sided.

A browser password manager is already installed, already syncing, already autofilling, and already has the extension that fills the login form on every site. It also has no file on your disk that you have to back up, no master password to remember, and no application to update. If your secrets are site logins and card numbers, it is very likely the better answer, and the migration story Rowel offers is really a story about moving away from it.

The difference in approach is the object model. Rowel treats an SSH key, an API key with its environment and scopes, and a .env file as things the vault knows how to hold, and it holds each item in its own sealed form inside the encrypted vault so the list and search work without exposing anything. A general purpose manager stores most of that as an attachment or a note, which means the secret is only as protected as the note around it and there is no structured view of which environment a key belongs to.

The other difference is the trust model. With Rowel the file is on your disk, encrypted under your master password, and the sync provider stores ciphertext in a folder the app can only reach. There is no server account to create and nothing to breach on someone else's side. That is a genuine advantage if you want to be able to say where your secrets live and who can read them, and it is a liability if you want a team administrator, a shared vault, or an audit trail, none of which the current product provides.

Editorial conclusion

Adopt Rowel if you want one encrypted vault on your own devices, if your secrets include SSH keys, API keys and .env files rather than only site logins, and if you are content to be the operator of the sync and the sharing paths. Do not adopt it as a team credential store, since the README describes a personal and family free app with a possible future paid tier for professional teams rather than a shared vault with roles. Verify first that the import path you need exists, since the supported sources are listed explicitly, and read docs/threat-model.md and SECURITY.md before you put anything you cannot lose into it. The licence is GPL-3.0, releases are frequent with v1.0.3 on 2026-10-15, and the last push was on 2026-10-17.

Frequently asked questions

Official sources

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