You have 47 API keys. You know where exactly zero of them are.
Your secrets are scattered across a digital wasteland. One is in a .env file you’re terrified to delete. Another is buried in a 2022 Slack DM. Your AWS credentials live in a Notion page titled "stuff", and your 2FA codes are trapped on a phone you're about to trade in. When you need an API key, you experience one of two realities: you find it in three seconds, or you spend 45 minutes regenerating it and updating six projects. There is no in-between.
This isn't a workflow problem. It is a missing tool problem.
Why Existing Tools Don't Solve It
When you look for a solution to this, you quickly realize the market is deeply polarized. You either get a consumer password manager or an enterprise infrastructure behemoth. Neither is built for the solo developer managing API keys, .env files, and recovery codes.
| Tool | The Reality |
|---|---|
| Bitwarden / 1Password | Built for website passwords (username/URL/password), not developer secrets. They lack dedicated metadata, rotation tracking, and are incredibly awkward for storing multi-line recovery codes or .env files. |
| Infisical / Doppler | Designed for engineering teams and CI/CD pipelines. You need a screwdriver; they are handing you an entire automated factory. Overkill for a solo dev. |
| HashiCorp Vault | You need a dedicated server and two weeks of free time just to understand the architecture before you can store a single key. |
| Notion / Apple Notes | Zero encryption at rest. Notion staff can read your secrets. You know this is a terrible idea. You still do it because it’s convenient. |
| KeePassXC | Phenomenal security, but no native cloud sync. Your phone has absolutely no idea your desktop vault exists. |
There is no tool that is personal-first, zero-knowledge, cross-platform, open source, and actually pleasant to use.
So, I built one. I call it Scync (Your secrets. Synced. Encrypted. Everywhere.). It’s an open-source, zero-knowledge secrets manager built specifically for developers.
The Architecture
To build Scync, I had a strict set of principles: one codebase for all platforms, zero-knowledge by default, and speed as a feature. The core loop of the app—Unlock vault → Find secret → Copy value—had to be instantaneous.
The Monorepo
Scync is structured as a Turborepo-managed monorepo using pnpm. The architecture strictly separates the UI and cryptographic logic from the deployment shells.
-
packages/core: The brain. Contains all the Web Crypto API logic, TypeScript types, and Firebase configurations. No UI code lives here. -
packages/ui: The shared React component library, design system (Tailwind CSS), and Zustand state stores. -
apps/web: The Vite + React web application (deployed as a PWA for mobile). -
apps/desktop: An Electron (v28+) wrapper around the web build.
Because of this structure, 100% of the React application logic is shared. There is no separate React Native codebase.
State Management & On-Demand Decryption
The state management, handled by Zustand, is where the security architecture dictates the software architecture.
In Scync, your plaintext secrets are never held in the global React state. The vaultStore only holds the CryptoKey (while unlocked) and an array of StoredSecret objects, which contain the encrypted AES-GCM blobs straight from Firestore.
Decryption happens on-demand. When you click "Copy" or "Show Value" on a secret, the app decrypts the value in memory, writes it to your clipboard (or renders it for 15 seconds), and immediately discards the plaintext. If a malicious script dumps your browser's heap memory, it will only find AES ciphertexts, not your OpenAI keys.
The Backend: Firebase (Blindly)
I chose Firebase for the backend because it offers real-time cross-device syncing via Firestore out of the box. However, Firebase is kept completely blind.
Scync separates Layer 1 (Identity) from Layer 2 (Encryption). Firebase Auth (Google Sign-In) handles your identity. It gives you a uid so Firestore knows which documents you are allowed to read. But Firebase Auth has nothing to do with decrypting your data. If someone hacks your Google account, they just get access to a database of mathematically unreadable blobs.
The Crypto Deep-Dive
"Zero-knowledge" is a term thrown around loosely in marketing. In Scync, it is enforced by math. The server never receives plaintext. The encryption implementation uses strictly the browser-native Web Crypto API—no third-party crypto libraries to audit.
Here is exactly how your data is protected.
1. Key Derivation (PBKDF2)
When you log in, you are prompted for a Vault Password. This password never leaves your device.
To derive the actual 256-bit AES encryption key from your human-readable password, Scync pulls a non-secret, 16-byte random salt from your Firebase metadata. It then concatenates your Vault Password with your Firebase uid (to prevent cross-account rainbow table attacks).
This combined material is run through PBKDF2 using a SHA-256 hash for 310,000 iterations (the OWASP 2023 recommendation). The output is a non-extractable CryptoKey object that lives entirely in your device's memory.
2. The Verifier Pattern
If we don't send the Vault Password to the server, and we don't store a hash of it, how does the app know if you typed the correct password when you try to unlock the vault?
We use an encrypted verifier.
During your first-time setup, after deriving your key, Scync takes the plaintext string "Scync_VALID_v1", encrypts it using AES-256-GCM, and stores the resulting ciphertext and Initialization Vector (IV) in your Firestore metadata.
Every time you unlock the vault subsequently:
- You type your password.
- Scync derives a temporary key in memory.
- It attempts to decrypt the stored
"Scync_VALID_v1"ciphertext using that temporary key. - If it succeeds, the password is correct, and the vault unlocks.
- If it throws an error (because AES-GCM includes an authentication tag that fails on wrong keys), the app knows the password was wrong. No password hashing required.
3. Encryption (AES-256-GCM)
Every single secret value and note is encrypted using AES-256-GCM.
Crucially, a fresh 12-byte random IV is generated for every single field, every single time it is saved. Even if you save the exact same API key twice, the resulting ciphertexts will look completely different. The ciphertext and the base64-encoded IV are packaged together and sent to Firestore.
(Note: Metadata like the secret's name and service are kept plaintext to allow for lightning-fast, real-time client-side searching without decrypting the entire database. A full-encryption mode is planned for V2).
4. Biometric Unlock via WebAuthn PRF
Typing a 20-character master password on a mobile device is miserable. But storing that password in plaintext defeats the purpose of a zero-knowledge architecture.
To solve this, Scync leverages the WebAuthn PRF (Pseudo-Random Function) extension.
When you enable FaceID or TouchID, your device's hardware (Secure Enclave/TPM) creates a deterministic symmetric key. Scync uses this hardware-level key to locally encrypt (or "wrap") your Vault Password, storing the wrapped version in your local storage.
When you use FaceID, the hardware re-derives the key, unwraps your Vault Password into memory, and feeds it into the PBKDF2 derivation function. You get native-speed unlocks without compromising the zero-knowledge model.
What I Learned
Building a secure, local-first application fundamentally changes how you view modern web development. Here are my biggest takeaways from building Scync:
1. The Web Crypto API is incredibly powerful (and underutilized).
Five years ago, building this would have required importing heavy, difficult-to-audit libraries like crypto-js or forge. Today, the native window.crypto.subtle API provides highly performant, NIST-standardized cryptography right in the browser. The fact that you can generate non-extractable keys—meaning even XSS attacks have a remarkably hard time stealing the actual key material from memory—is a massive win for frontend security.
2. "Opinionated Simplicity" is the hardest feature to defend.
When you build a tool for developers, the immediate feedback is always: "Can you add custom fields? Can you add a plugin architecture? Can you add programmable webhooks?"
It takes immense discipline to say no. Scync forces you to categorize your secrets by environment, service, and type. It natively understands that a .env file is different from a Recovery Code set. By refusing to make it a generic "custom field" database, the UI remains calm, the search remains instant, and the tool remains highly specialized for its actual purpose.
3. State management with raw encrypted data forces better architecture.
Usually, you fetch data from an API, dump it into a Redux or Zustand store, and map over it in your UI. In Scync, doing that would mean keeping dozens of highly sensitive API keys sitting in plaintext memory.
Building an architecture where components rely entirely on encrypted state, and only trigger an async decryption function at the exact millisecond of user interaction (like copying to the clipboard), taught me a lot about strict data lifecycles. It’s a slightly heavier development burden, but the security guarantee is worth it.
Try it / Star it
Scync was built because I was tired of pasting my AWS keys into Notion, and I suspect I'm not the only one.
The project is completely open-source under the MIT License. It will remain free, and there is no "enterprise pricing tier" waiting to trap you.
If you're a developer dealing with the "47 API keys" problem, I invite you to try it out, tear apart the cryptographic implementation, or host your own instance.
- Check out the code and star the repo: github.com/hariharen9/Scync
- Live application: Scync.space
- Read the Security Spec: The complete zero-knowledge architecture and threat model is detailed in
SECURITY.mdin the repo.
Pull requests are welcome, especially if they make the core loop—Unlock → Find → Copy—even faster.
Top comments (0)