Why We Built CloudKeep

Most secrets managers were designed for operations teams. They assume you want a GUI, a mouse, and a lot of clicking. Developers deserve better.

CloudKeep is built by developers, for developers. Every decision we make starts with the same question: "How would I want to use this from a terminal?"

What Makes CloudKeep Different

Zero-Knowledge Encryption

Your master password never leaves your device. We derive an encryption key locally using PBKDF2 with 600,000 iterations, then encrypt every secret with NaCl secretbox before it touches our servers. We literally cannot read your data — even if compelled to.

Developer-First Tooling

CloudKeep ships with a CLI and a REST API from day one. Inject secrets into your process environment with a single command:

# Inject secrets from the "production" vault into your app
cloudkeep inject --vault production -- node server.js

# Or fetch a single value
export DB_URL=$(cloudkeep get production/DATABASE_URL)

No more .env files littering your repositories.

Team Collaboration

Share vaults with your team using role-based permissions. Owners, admins, members, and read-only viewers — everyone gets exactly the access they need and nothing more.

Organizations group people and vaults together.
Audit logs track every read, write, and permission change.
Access requests let team members ask for elevated access with a clear approval workflow.

What to Expect

We are just getting started. Here is what is on the roadmap:

CLI v2 with shell completions and interactive secret creation
Browser extension for autofill of credentials
CI/CD integrations for GitHub Actions, GitLab CI, and CircleCI
Secret rotation with automatic provider integrations

We will share updates here on the blog, so subscribe to the RSS feed or check back regularly. If you have feature requests, open an issue on our GitHub repository.

Welcome aboard. Your secrets are safe with us.