Secret manager for macOS (developer-focused)

Before adding software, it's worth knowing what your Mac already does. FileVault, Keychain Services, the Secure Enclave, and screen lock are all present and all doing real work — and each one covers a different threat, with gaps between them.

Most advice about "securing secrets on macOS" fails by treating these as interchangeable. They aren't. FileVault does nothing while you're logged in. Keychain can't lock itself during your session. Understanding which gap each layer leaves is what tells you whether you need another tool at all.

This guide maps the layers honestly, then explains where a developer-first vault like PassStore belongs — and where it doesn't.

---

1. The layers, and what each one actually covers#

The pattern worth internalising: layers 1–3 protect you when you're away from the machine. Most of your working day is spent logged in with the screen unlocked, and during those hours a plaintext .env file is just a file.

That's the gap. Everything below is about whether you need to close it.

FileVault: the floor#

Modern Macs encrypt the internal SSD in hardware regardless. What FileVault adds is binding the decryption key to your credentials — without it, the key is available to anything that can boot the machine, so a stolen laptop is a stolen .env file.

# Should print "FileVault is On."
fdesetup status

If it doesn't, that's your first action: System Settings → Privacy & Security → FileVault. (Apple: FileVault)

The limitation people misread: FileVault protects data at rest. Once you log in, the volume is decrypted for the whole session and every process running as you reads your files in plaintext.

Screen lock: the layer left at 20 minutes#

# 0 = require password immediately after sleep or screen saver
defaults read com.apple.screensaver askForPasswordDelay

Set it to immediate in System Settings → Lock Screen, and make locking reflexive: Control-Command-Q, or a Hot Corner. More: how to auto-lock sensitive data on macOS.

---

2. Apple Keychain: where it's genuinely enough#

Keychain Services is well-designed, hardware-backed, and free. For these, it's the correct answer and you need nothing else:

• Wi-Fi passwords
• Safari logins and passkeys
• Certificates and code-signing identities
• Occasional one-off secrets

For developer workflows at scale it runs into structural limits — not bugs, but consequences of what it's for:

# Works fine. Note the secret lands in shell history and in ps output.
security add-generic-password -a "$USER" -s STRIPE_KEY -w 'sk_test_...'

# Prompt instead, to keep it out of history
security add-generic-password -a "$USER" -s STRIPE_KEY -w

security find-generic-password -s STRIPE_KEY -w
security delete-generic-password -s STRIPE_KEY

• Your login keychain unlocks at login and stays unlocked for the session. That's why apps don't prompt constantly, and it means Keychain cannot offer auto-lock. Per-item ACLs restrict which app can read an item without prompting — useful against unrelated apps, not against something impersonating your workflow. Keychain is not a boundary against local code execution.
• No project grouping. Item names become a convention you invented and will forget.
• No rotation metadata. Nothing records when a value changed or what scope it has.
• Bulk UX is poor. Keychain Access.app is not built for forty developer secrets across twelve repos.
• Sync behaviour needs checking. iCloud Keychain syncs items marked synchronizable. security-created items are local-only by default, but applications can create synced items. If "nothing leaves this Mac" is a hard requirement, verify per item.

Detail: macOS Keychain for developers · Keychain vs .env files.

---

3. Choosing a category#

The decision that matters most isn't which app — it's whether you need sharing. Sharing requires a server: access control, revocation when someone leaves, an audit trail. A local-first tool cannot provide those, and any tool claiming both is worth reading carefully.

Comparisons: best macOS apps for API keys · 1Password vs a local secret manager · local-first vs cloud secret managers · open source secret managers compared.

---

4. What to require from a macOS developer secret manager#

1. Encryption at rest with named algorithms. Authenticated encryption (AES-GCM or ChaCha20-Poly1305) and a memory-hard KDF (Argon2id, scrypt). If the marketing says "military-grade" and the docs don't name a cipher, that's a signal.
2. Auto-lock during your session. The one thing the OS layers can't do for you.
3. Clipboard auto-clear. The pasteboard is the real transport for secrets on a Mac, readable by every process running as you, and persisted to disk by most clipboard-history apps.
4. Project and environment grouping, so staging can't accidentally point at the live payments key.
5. A working export. Any manager you can't leave has you hostage. Test it on day one.
6. An honest threat model in the docs, including what the tool does not do.
7. Native, not Electron — for launch speed and memory, and because a secret manager that takes four seconds to open is one you'll route around.

---

5. Local-first vs syncing to a vendor#

Some tools sync secrets through their cloud by default. That's often fine — the encryption is usually sound and your data leaves encrypted. But it's a different trade-off, and worth making deliberately.

The recovery row is the honest cost of local-first and deserves emphasis: no account means nobody can help you. Forget the master password with no backup and the vault is gone. Take encrypted backups and verify you can restore them.

What local-first buys is not better cryptography — it's removing a category of risk rather than mitigating it. Whether that's worth losing sync, sharing, and recovery is a personal call. For a team, the answer is usually no.

---

6. What no macOS secret manager can promise#

Direct, because a tool you over-trust is worse than one you understand:

• Malware running as your user while the vault is unlocked. It can read decrypted memory, your clipboard, and anything on screen. Auto-lock narrows the window; nothing closes it.
• A malicious npm or pip dependency. A postinstall script with your privileges is inside the boundary, not outside it.
• You pasting a key into Slack, a ticket, or an LLM chat. The most common exfiltration path in practice, and storage cannot address it.
• Phishing.
• A key already in Git history. Only revocation ends that. I accidentally committed an API key.
• Secrets published in a client bundle. NEXT_PUBLIC_* and VITE_* are inlined into browser JavaScript at build time. An architecture problem, not a storage one. Preventing frontend key leaks.
• Backups you forgot about. Time Machine keeps deleted files; a .env you removed months ago may still be restorable.

PassStore's threat model states these plainly: Security.

---

7. Habits beat products#

The controls that prevent the most incidents cost nothing:

• Test keys locally, production keys never. The highest-leverage rule in this entire guide, and the most frequently broken.
• Scope narrowly. A read-only token beats an admin token you rotate diligently.
• Prefer short-lived credentials. aws sso login, OIDC in CI, GitHub App tokens. Something that expired an hour ago is not an incident.
• One key per project. Reuse turns a small leak into a large one.
• Never export secrets in .zshrc. Every process in every terminal inherits them, forever.
• Move projects out of iCloud-synced folders. ~/Developer, not ~/Documents.
• Run a pre-commit scanner, so the rule is enforced rather than remembered:

  brew install gitleaks && gitleaks protect --staged --redact
  

Process reading: keep secrets out of Git · a practical developer secret management setup for 2026.

---

8. How PassStore fits#

• AES-256-GCM vault encryption; Argon2id password-based key derivation
• Touch ID / Secure Enclave unlock, or master password
• Auto-lock and clipboard auto-clear
• No cloud sync, no account server — no backend exists for data to reach
• Workspace grouping per project; API keys, .env groups, database URLs, and SSH credentials as distinct types
• Vault health audit for reused and weak secrets
• Command palette and menu bar access
• Encrypted backup export and import
• Native Swift/SwiftUI, macOS 26.0+, free and MIT

Because it's open source, the "no network calls" claim is verifiable rather than something you take on faith — which for a security tool is a categorical difference, not a marketing line.

Download for macOS · Security overview

---

Does macOS have a built-in secret manager?#

Yes — Keychain Services, with Keychain Access.app as its interface. For Wi-Fi passwords, certificates, Safari logins, and occasional one-off secrets it's genuinely sufficient and you should use it.

It falls short for developer work in three specific ways: it can't auto-lock (the login keychain stays unlocked all session), it has no project or environment model, and it stores no rotation metadata. Those aren't gaps a script fixes — they're consequences of what Keychain is designed for.

The productive framing is that a developer vault sits on top of Keychain rather than replacing it: Keychain and the Secure Enclave handle unlock, and the vault adds the organisation, auto-lock, and audit layer above it.

---

Is a Mac secure enough without a secret manager?#

For non-secret config, yes. FileVault plus prompt screen lock plus disciplined .gitignore is a reasonable baseline, and a tool adds overhead without much benefit.

You've outgrown that when: you have credentials with real blast radius in plaintext files; you work across enough projects that you've lost track of what you have; you've had a near-miss with git add .; you need to rotate and can't tell where a value lives; or the same key exists in several places and you don't know which is current.

The practical threshold is around five projects or the first near-miss, whichever comes first.

---

macOS-focused articles#

• Where to store secrets on macOS securely
• Keychain vs .env files (complete comparison)
• macOS Keychain for developers: storing API keys safely
• How to auto-lock sensitive data on macOS
• Secure storage for database credentials on macOS
• Where to store SSH keys safely (besides ~/.ssh)
• How to manage secrets without using cloud tools
• The safest way to store API keys locally
• Guide: API key manager
• Guide: Environment variable manager