I've been writing code for more than 25 years. I've seen languages come and go, frameworks rise and fall, and deployment go from FTP to git push. But one thing has remained stubbornly broken the entire time: sharing environment variables.
The Same Problem, Everywhere
Right now, I'm a CTO working with 20+ dev teams. And I keep seeing the exact same scene play out, in every single team.
Over my career, I've worked across dozens of industries and company sizes, from early-stage startups to mature organizations. The stacks change, the maturity levels vary, but this particular problem? Always the same.
A deploy fails in production. Someone forgot to add STRIPE_WEBHOOK_SECRET to Vercel. The variable exists in the local .env of the dev who wrote the feature, but it never made it to staging or prod. Nobody noticed until customers started complaining.
Or: a new dev joins the team. Day one, they clone the repo, run npm install, then npm run dev. Nothing works. They spend the next three hours hunting down credentials, asking on Slack, digging through Notion, finding a .env.example that's six months out of date. Their first commit? Updating the example file.
Or my personal favorite: someone leaves the company. A month later, the team realizes that dev was the only one who had the API keys for a critical integration. The keys are in their local .env, which is now on a wiped laptop somewhere.
I've seen this movie too many times.
What Teams Actually Do
Here's what "env management" looks like in most teams I work with:
There's a .env.example in the repo. It was accurate when it was created. That was two years ago. Now it's missing half the variables and has comments like # ask John for this one (John left in March).
New variables get shared on Slack. "Hey can someone send me the Resend API key?" Then it sits there, in plaintext, in a searchable chat history, forever.
Some teams use a shared 1Password vault. It works, kind of, until you need to add a variable and update it in 1Password AND Vercel AND tell everyone to re-pull. Nobody remembers all three steps.
The sophisticated teams have a wiki page. It's always wrong.
What I Tried
I looked at the existing solutions. I really did.
Doppler is capable, but it's not frictionless. There's a learning curve, a CLI to configure, projects to set up, environments to map. It works once it's working, but you have to convince your team to adopt it first. I wanted something where the barrier is so low that there's nothing to convince: run three commands, it works, move on with your day.
HashiCorp Vault is the industry standard for a reason, if you have a dedicated DevOps team to run it. The learning curve is steep, the operational overhead is real, and it's massive overkill for "I just want my team to have the same .env file."
dotenvx is clever and I like the approach, but it's encryption-only. No cloud sync. You still need to figure out how to share the keys.
1Password for Developers is a password manager with dev features bolted on. It works, but it wasn't designed for this workflow. The mental model doesn't fit.
What I wanted was simple: push my .env somewhere secure, let my teammates pull it, sync it to Vercel when I deploy. That's it. Three commands, no YAML, no dashboards I have to babysit.
So I Built It
Keyway does exactly that. Here's the entire workflow:
# First time setup
keyway init
# Share your env with the team
keyway push
# Teammate gets the env
keyway pull
# Sync to Vercel before deploy
keyway sync vercel
That's genuinely it. No config files. No YAML. No tokens to manage manually.
The auth uses GitHub: if you have access to the repo, you have access to its secrets. When someone leaves the team and loses repo access, they lose secret access automatically. No manual revocation.
Everything is encrypted with AES-256-GCM. I can't read your secrets. Nobody at Keyway can. The infrastructure runs in the EU on Railway, GDPR-compliant by default.
Who This Is For (And Who It Isn't)
Keyway is for small teams and solo devs who want the env problem to just go away. If you're building side projects, working in a startup with 2-5 devs, or just tired of the Slack-based secrets dance, this is for you.
It's free for public repos. Unlimited everything. If you're building open source, you shouldn't have to pay to manage your config.
For private repos, it's $9/month for unlimited secrets, unlimited projects, unlimited team members. No per-seat pricing that punishes you for growing.
Here's who Keyway is not for:
If you need SOC 2 compliance, audit logs, or enterprise SSO, use Doppler or Vault. Those are real requirements and Keyway doesn't address them yet.
That said, security isn't an afterthought. After 25+ years building software, I know that security by design is the only approach that works. Check the security page to see how seriously I take it.
If you're a large organization with complex access control needs, Keyway's GitHub-based permissions model might be too simple. That's a feature for my target users, but a limitation for yours.
If you need to rotate secrets automatically or integrate with Kubernetes, there are better tools. Keyway syncs .env files. It's not a full secrets management platform.
The Boring Truth
I built Keyway because I was fed up with managing env variables, and everything on the market was either too complex or too expensive for what I actually needed.
It's not revolutionary. It's not going to change the world. It's a small tool that solves a specific, annoying problem that I kept running into.
If that problem sounds familiar, give it a try: keyway.sh
I'm Nicolas, solo founder of Keyway. If you have questions or feedback, I read every email: hello@keyway.sh