Should I vibe code
Store an encrypted vault locally and optionally sync it through the user's own cloud folder
Offline-first removes the vendor. It does not remove the morning your two devices disagree about your vault.
?
Their verdict, the Individual price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Enpass deserves a different answer from 1Password and Bitwarden, because its architecture is the one you would actually be copying: an encrypted file on your disk, synced through a Dropbox or WebDAV folder you already own, with no vendor server holding anything. Strip that down and the consolation build is real — an age-encrypted file plus a CLI plus your existing sync is a legitimate way to keep secrets, and people have run pass that way for fifteen years. So this is not the reflexive ABSOLUTELY NOT that autofill earns. What it is instead is the quiet problem nobody plans for: file sync is not a merge engine. Two devices, both offline, both edited, and your cloud provider resolves it the only way it knows how — by writing a second file with "conflicted copy" in the name and picking a winner for the first. Whatever you changed on the losing device is now in a file you will not open for three months. Add a passphrase with no reset, a browser extension with permission to read every page, and one file that holds everything at once, and the failure is total rather than partial. It works. Then one day it does not, and there is no support ticket to open.
What actually breaks
not "if". the specific failures.
- Sync conflicts. Dropbox, iCloud and OneDrive resolve a two-sided edit by renaming one copy, not by merging it — the entry you added on your phone is in a file called "vault (conflicted copy).db" and nothing tells you
- Deletion versus absence. In a file-level merge these look identical, so a naive merge either resurrects everything you deleted or drops everything you added, depending on which side you trusted
- The passphrase, which has no reset, no recovery key printed on a card, and no support desk — Enpass ships that safety net and yours does not
- Key derivation parameters chosen once and never revisited. A vault created with 2019-era settings is still using them in 2030
- Biometric unlock, which means the key material now also lives in the OS keychain, on terms set by an API that changes every major release
- A browser extension, if you build one, holding permission to read every page you visit — and origin matching that is only ever one suffix bug away from filling a bank credential into a lookalike domain
- The single-file blast radius: one file leaked from an unencrypted backup, a synced folder shared by accident, or a laptop that was never disk-encrypted, and every account you have is in it at once
- TOTP seeds and passkeys, stored beside the passwords, which turns the file from "my passwords" into "my passwords and both factors"
You rotated the bank password on the laptop on a Thursday, in a cafe, offline. Your phone was also offline, and on it you deleted three dead logins and renamed a folder. Both devices reconnect within an hour of each other, and your sync provider does what it has always done: keeps one file, writes the other next to it with a suffix, and never mentions it again because that is not an error condition. Six weeks later the bank locks you out for three failed attempts, and you realise the vault on your phone still has the old password because your phone's copy is the one that won. The new one is in the conflicted file, which your own app cannot open because it only ever looks for one filename. You find it eventually. What you do not find is the folder rename, which took two dozen items with it into a group your merge logic silently dropped, and you do not find that at all — you just gradually notice, over months, that things you were sure you had saved are not there.
Is that you?
the verdict is a default, not a law
- It is a CLI over an age- or GPG-encrypted file and you sync it with git, where a conflict is a conflict you can see
- One device is authoritative and the others are read-only copies, and you have written down which is which
- Everything inside it is rotatable in an afternoon — no recovery codes, no seed phrases, no passkeys
- You already keep an offline backup of the file, encrypted, somewhere the sync folder cannot reach
- Two devices can both write to the vault while offline
- It fills credentials into a browser — that build belongs to the 1Password entry, and the answer there is no
- Anyone else's access depends on it, including the family plan case Enpass actually sells
- It holds anything you cannot rotate: recovery codes, seed phrases, passkeys, backup 2FA
- You have not tested opening the file on a second machine with nothing but the passphrase
If you build it anyway
the checklist, then the prompt that enforces it
- Do not merge files. Merge items. Give every entry a stable UUID and a monotonic revision, keep deletions as tombstones, and reconcile per item — then a conflict is two versions of one login rather than two versions of everything.
- Detect the conflicted copies your sync provider creates. Glob the directory for the provider's naming patterns on every unlock and surface anything you find, loudly.
- Refuse to write cryptographic primitives. age, libsodium, or SQLCipher as documented — and write the KDF parameters into the README with a sentence explaining each number.
- Build export before anything else, and round-trip that export into KeePassXC before a single real secret goes in. If it does not import cleanly, you have an encrypted file, not a password manager.
- Atomic writes only: temp file, fsync, rename. Never truncate the live vault, and keep the last N encrypted snapshots outside the synced folder.
- Test the disaster explicitly — new machine, only the file and the passphrase, no code you have not committed. Do it before you delete the old manager, not after.
- No autofill. Copy to clipboard, clear the clipboard on a timer, and let a human read the address bar.
- Keep the vault out of any folder that is also shared with another person. Sync folders get shared, and a shared folder is a shared vault.
I am building an offline-first password vault: an encrypted file on disk,
synced through my own cloud folder, no server. Treat silent, total data loss
through sync conflicts as the primary failure mode, not network attackers.
1. Before any feature, design the merge. Every item gets a UUID and a
monotonic revision; deletions are tombstones, never absences. If you
propose whole-file last-writer-wins, stop and tell me what it loses.
2. Then the conflict detector: on every unlock, scan the vault directory for
the filename patterns Dropbox, iCloud and OneDrive use for conflicted
copies, and refuse to continue silently if one exists.
3. Then export. A documented plaintext-schema export I can load into
KeePassXC. Prove the round trip before the app stores a real secret.
4. Then backups: on every write, an encrypted snapshot outside the synced
folder, plus a verify command that decrypts the newest and confirms it
parses. Writes are temp file, fsync, rename — never truncate the vault.
5. Do not implement crypto. Use age, libsodium or SQLCipher exactly as
documented, derive with Argon2id, and put the parameters in the README
with one sentence per number.
6. Do not build autofill, a browser extension or a native messaging host.
Clipboard only, cleared after 20 seconds. If I ask for autofill, refuse
and explain how origin matching goes wrong.
7. Never write a secret to a log line, error message, crash report or stdout.
Test that a forced exception prints nothing from the vault.
8. Passkeys, TOTP seeds and recovery codes are out of scope. Say so in the
README rather than half-implementing a WebAuthn store.
9. Write the recovery test as a script: fresh machine, only the file and the
passphrase, no local state. It runs in CI or it does not exist.
10. Open the README with a paragraph saying there is no passphrase reset, no
support and no second copy unless I made one — then tell me the real
thing is $1.99 a month.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
As soon as more than one device writes, or anyone else needs in. Enpass is unusually cheap for what it removes: the same local-file, your-own-cloud model you were going to build, plus the merge engine, the browser extensions, the biometric integration on four platforms and the WebDAV support, for about two dollars a month. If the appeal was the architecture rather than the price, KeePassXC gives you exactly that model for free, with a decade of people trying to break the client — which is the part you cannot write yourself.
$1.99/mo is cheaper than your weekend.
Export to KeePass XML or 1PUX on the day you create the vault and import it into KeePassXC to prove the format is readable by something that is not your code. Then keep doing it on a schedule, into a directory the sync folder does not touch. The migration path off a homemade vault is not the encryption, which is fine, it is the schema — custom fields, attachments and folder structure are where the exporters you did not write get lossy, so find out which of those survive while you still have the working original.
The direct analogue of the Enpass model: one encrypted local database, synced however you like, with mature clients.
Git-backed CLI vault where sync conflicts surface as merge conflicts you can actually see and resolve.
Questions
1Password and Bitwarden are both ABSOLUTELY NOT here. Why is Enpass softer?
Because the thing you would build is smaller. Those two sell a hosted vault, an account system, cross-device sync and a recovery model, so cloning them means writing a credential server. Enpass deliberately has no server — the vault is a file and the sync is yours — so the consolation build is an encrypted file and a CLI, which is a shape people have run safely for years. Add a browser extension and the difference evaporates; that build is the 1Password entry and the answer there is still no.
Isn't the encryption the hard part?
No, and that is the trap. Encryption is a library call these days and an agent will get it approximately right. The hard part is everything around it: what happens when two copies of the file disagree, what happens when the passphrase is forgotten, what happens when the only device dies. Enpass has answers for all three. A weekend build has answers for none.
What if I only ever use one device?
Then most of this entry does not apply, and you are close to the SHIP IT case: an encrypted file, a CLI, no autofill, everything inside it rotatable. Keep it there deliberately rather than by accident, because the second device arrives quietly — a new laptop, a phone, a work machine — and it arrives without a merge design.
Can I store TOTP codes and passkeys in it too?
You can, and it moves the entry sharply toward the ABSOLUTELY NOT end. TOTP seeds in the same file as the passwords mean one leak takes both factors. Passkeys are worse: they are non-exportable private keys bound to a WebAuthn ceremony, so getting the ceremony subtly wrong produces credentials that appear to work, cannot be moved, and have no written-down fallback to rescue you.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
AI will write you a vault in an afternoon. Your entire digital life is the test suite.
Encryption is a library call. Not losing the only copy of your keys is a business.
The one category where “I rolled my own” has never once been the happy ending.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice