Omazy Secrets | Local-First Secrets Management for Developers

Built for Developers

Zero-knowledge architecture with native AI agent support

Directory Context

Secrets automatically load when you enter a directory and unload when you leave.

URI References

Reference secrets as om://vault/item/field URIs. No more hardcoded credentials.

AI Agent Support

Native MCP integration. AI agents can query secrets with human approval gates.

CLI First

Built as a Rust CLI with daemon. Fast, secure, and works offline.

Zero Knowledge

AES-256-GCM encryption. Master key never leaves your machine.

Team Ready

Service accounts, RBAC, audit logs, and self-hosted Connect Server.

How It Works

Get started in under one minute with our simple workflow.

Map Environment

Create a vault environment mapped to your project directory, then trust it once with om allow — secrets load automatically on every cd.

# create a named environment linked to your vault

$ om env create "App-Dev" \

--vault "MyVault" \

--dir ~/projects/app

✓ Environment "App-Dev" mapped to ~/projects/app

# trust the config once per project

$ om allow

✓ Config trusted. Secrets will auto-load on cd.

Run Commands

Prefix any command with om run to inject secrets into the process environment at runtime — nothing is written to disk.

# inject secrets into any process

$ om run -- node app.js

✓ Injected 5 secrets [App-Dev] into node.

# works with any runtime

$ om run -- python server.py

✓ Injected 5 secrets [App-Dev] into python.

# or start a secret-aware shell

$ om shell

✓ Spawned shell with [App-Dev] active.

Deploy

Render secret-injected config files from .tpl templates at deploy time — no plaintext secrets ever touch your repo or CI logs.

# render a template with live secrets

$ om inject \

-i deployment.yml.tpl \

-o deployment.yml

✓ Rendered deployment.yml (3 secrets injected).

# then deploy as usual

$ kubectl apply -f deployment.yml

✓ deployment.apps/app configured.

Full Workflow Example

End-to-end integration of om CLI — from environment setup to secret-injected deployment.

~ bash

# 1. Sign in and unlock the daemon

$ om signin

✓ Authenticated. Daemon running.

# 2. Create a vault and map it to your project directory

$ om vault create "MyVault"

$ om env create "App-Dev" --vault "MyVault" --dir ~/projects/app

✓ Environment "App-Dev" mapped to ~/projects/app

# 3. Trust the directory config (once per project)

$ om allow

✓ Config trusted.

# 4. Run your app — secrets injected automatically

$ om run -- node app.js

✓ Injected 4 secrets into process environment.

# 5. Render deployment config from template

$ om inject -i deployment.yml.tpl -o deployment.yml

✓ Written deployment.yml with secrets resolved.

Team Secrets Sync

John pushed a new environment to the shared vault. Your CLI detects the update and prompts you to sync.

~ zsh · ~/projects/app

# John pushed a new env "Staging" to the shared vault

SYNC john@omazy pushed "Staging" to vault "MyVault" · 2 min ago

Do you want to sync this environment? [y/N] █

$ om sync --env Staging

✓ Pulling "Staging" from vault "MyVault"...

✓ 6 secrets merged. 1 conflict resolved locally.

✓ Environment "Staging" is up to date.

# Run your app with the synced staging secrets

$ om run --env Staging -- node app.js

✓ Injected 6 secrets [Staging] into process environment.

Get Early Access

Get Started in 5 Minutes

Omazy Secrets is currently in private alpha. Request early access below — we'll send you installation instructions when you're approved.

macOS

brew install omazy/tap/om

Linux

curl -sL https://secrets.omazy.ai/install.sh | bash

Windows

iwr https://secrets.omazy.ai/install.ps1 -useb | iex

Shell Support

Native integration with bash and zsh. One command to wire up auto-injection for every new shell session.

Bash

~/.bashrc · ~/.bash_profile

~ bash

# Add om hook to your shell profile

$ om shell init --shell bash >> ~/.bashrc

$ source ~/.bashrc

# om now auto-injects secrets when you cd into a mapped dir

$ cd ~/projects/app

✓ [om] Loaded "App-Dev" — 4 secrets active.

Zsh

~/.zshrc · Oh-My-Zsh plugin

~ zsh

# Add om hook to zsh

$ om shell init --shell zsh >> ~/.zshrc

$ source ~/.zshrc

# Works with Oh-My-Zsh and Starship out of the box

$ cd ~/projects/api

✓ [om] Loaded "API-Dev" — 7 secrets active.

$ cd ~/projects/app

✓ [om] Switched to "App-Dev" — 4 secrets active.

Auto-loads on cd Scoped per directory Zero env var leakage Works with tmux & screen Oh-My-Zsh compatible Starship prompt ready

Team Sync with om sync

Secrets flow securely from dev to production — encrypted end-to-end, audited per push, and zero plaintext on the wire.

DEVELOPMENT

John pushed 3 secrets

2 min ago

You

You synced +1 local

just now

Sara watching "App-Dev"

online

MyVault

App-Dev API-Dev Production

PRODUCTION

CI/CD Pipeline om inject --env Produ…

✓

Deploy Server secrets injected at r…

✓

om sync in action

Push your dev secrets to the shared vault, promote to production — all from the CLI.

~ zsh · ~/projects/app

# Check what your teammates have pushed

$ om sync status

john@omazy → "Staging" +3 secrets 2 min ago

sara@omazy → "App-Dev" +1 secret 5 min ago

# Pull the latest from the shared vault

$ om sync pull --env App-Dev

✓ Pulled "App-Dev" — 7 secrets (1 updated, 6 unchanged).

# Add a new secret locally and push to team

$ om secret set STRIPE_KEY=sk_live_••••••••

$ om sync push --env App-Dev

✓ Encrypted and pushed STRIPE_KEY to "MyVault/App-Dev".

john, sara will be notified.

# Promote dev secrets to production vault

$ om sync promote --from App-Dev --to Production

✓ 7 secrets promoted to "Production" vault.

Audit log updated. Access: CI/CD only.

Honest Comparison

Why Developers Choose Omazy Secrets

Enterprise tools solve enterprise problems — servers, budgets, and ops teams. Neither HashiCorp Vault nor 1Password CLI was designed for a developer's laptop. See how Omazy Secrets compares.

Scroll horizontally on mobile

Best for Devs

Enterprise infrastructure

Password manager + CLI

Omazy Secrets

Local-first secrets

Server Required

Runs vault server always

1Password cloud (always on)

Zero — local binary only

Works Offline

Server must be running

Cloud required

Yes — fully offline

New Dev Onboarding

10+ steps, write HCL policies

Paid subscription + desktop app

om init — done

Auto Project Context

Manual path management

Manual vault/item naming

Auto-loads on cd

CI/CD Setup

Spin up Vault in CI runner

Business plan + Service Accounts

Same encrypted file, zero setup

Cost

Free (BSL risk)

$3–20+/month per user

Free

License

BSL — legal uncertainty

Vendor lock-in

MIT

Auth Interruptions

None (token-based)

Popup storm on parallel processes

None — key unlocks on demand

HashiCorp Vault Reality

"There are over 200 topics complex enough in HashiCorp Vault to deserve a complete tutorial. If we want secrets management to be mainstream in small projects, it needs to be much simpler."

— Developer on HN, Nov 2020

1Password CLI Reality

"Every time I open a new Cursor window, it triggers 12+ biometric prompts simultaneously — one per MCP server. I have to click Approve 12 times in a row just to start working."

— u/Rough_Suggestion_390, r/1Password, May 2025

The Universal Pain

"The breaking point came when every solution we tried made deployments dependent on external services. Someone needs the staging DB URL, so it gets shared over Slack."

— Developer on HN, Jul 2025

Built for the way developers actually work

No servers to spin up. No subscription required. No secrets shared over Slack. One binary, one command, and your secrets are encrypted locally — always available, offline, and never leaving your machine.

Get Started Free

Every Developer Has Been Here

Secrets management is broken at every phase of development. These are real problems — not edge cases.

r/webdev ↑ 2.4k

"Accidentally committed my .env file with real AWS keys to a public GitHub repo. Got a $4,200 bill the next morning from someone mining crypto. GitHub's secret scanning caught it 6 hours too late."

u/burned_by_aws · 847 comments

@swyx 1.1k likes

"new dev joined the team. day 1. someone had to DM them the .env file over Slack. the file had prod DB creds in it. this is the industry standard apparently"

@swyx · 312 retweets

r/devops ↑ 891

"Our entire team of 8 devs all have a slightly different version of the .env file. Nobody knows which is canonical. We've had three outages this month because someone ran with stale creds."

u/env_hell_survivor · 203 comments

YouTube comment ↑ 634 likes

"Every tutorial says 'add your API key here' and 'don't commit your .env'. But nobody explains how to actually share secrets with your team without emailing them around or putting them in Notion."

on Fireship · "Never store secrets in .env files"

@t3dotgg 2.8k likes

"the .env file is just a shared password in a text file that lives on everyone's laptop. we've spent 20 years building zero-trust networks and then we do this"

@t3dotgg · 741 retweets

r/netsec ↑ 3.1k

"Rotated a production secret. Forgot to update it on two servers. Both crashed at 2am. Spent 4 hours debugging. The secret was still hardcoded in a config file nobody knew existed."

u/3am_oncall_regrets · 512 comments

Developer Pains

Development Phase

.env files on every machine. Real credentials sitting in plaintext on every developer's laptop, one accidental commit away from exposure.
Secrets shared over Slack and email. New hire? Someone DMs them the .env file. It's now in chat history, email threads, and Notion pages forever.
No single source of truth. Every dev has a slightly different version of the file. Nobody knows which is canonical until something breaks in production.
Committed to git — always too late. Secret scanning catches it hours after the push. The key is already burned. You're rotating at 2am.

Slack Integration — the right way

om connects to Slack for activity notifications and secret lookups — but never shares actual values. References are shared as om://MyVault/App-Dev/STRIPE_KEY URIs. The recipient resolves it locally through their own authenticated om daemon. The secret never leaves their machine.

Developer Pains

Production Phase

Secrets baked into images and CI vars. Docker images built with env vars in the layer history. CI pipelines with secrets in plain environment variables visible to every runner.
Rotation is a production incident. One secret change means hunting every server, container, and config file it touches. Miss one and it crashes at the worst moment.
No audit trail. No way to know which service accessed what credential, when, or from where. Compliance is impossible. Breaches go undetected.
Dev–prod drift causes silent failures. Dev uses a test key, prod uses a real one. The bug only appears in production, at scale, under load.

One tool. Both phases.

om

Omazy Secrets CLI

Secrets live in an encrypted local vault, sync end-to-end across your team, and inject at runtime only. No plaintext. No .env files. No sharing over chat. No disk writes.

Encrypted local vault — replaces every .env file on every machine

Team sync via om sync — E2E encrypted, no Slack, no email

Slack integration notifies and links — actual values stay local

Full audit log — every access, push, pull, and rotation tracked

Promote dev → production in one command, access-gated

Runtime injection only — nothing written to disk or git, ever

Install om CLI

Stop Shipping Secrets.env FilesAPI KeysPasswordsTokensCredentialsSecrets