Secrets are used by every development projects.
In most case, they are shared in insecure ways and not synced with the project itself.
It brings bugs at many levels: among the team on their local environments, at the CI/CD stage and even in production.
Existing tools are either lacking transparency or too hard for small teams to use and maintain on the long run.
That’s why we created Keystone.sh.
As developers ourselves, we wanted a simple tool to share and use sensitive data like certificates, credentials and environment variables.
It had to be fully open source, secure, agnostic from programming languages and terminal based. It had to work seamlessly with the platforms and tools we use every day: git, github, gitlab, CI/CD pipelines and so on.
Syncing secrets or how to solve issues before it happens.
How many times have you asked one of your colleague to send you a .env file? We guess it’s too much.
Missing config and secrets is a waste of time for any developers. Just like we want our code to be synced with others, configuration and secrets should be too.
More than that: we want to know the secrets our current codebase version requires. In other words, which secrets I need for my current commit.
It can be worst when your production environment fails because it’s not using the last config version.
Knowing that everything is in sync, from your team to your environments, provides peace of mind.
Open source vs. proprietary software
We weren’t confident to invest in a closed-source solution like Doppler or EnvKey for example. While they both look to do a good job, we wanted to avoid a lock-in.
Imagine if they close their service or make a change that doesn’t suit you? You are good to find another service and update all your projects. That’s a hard dependency.
However with a fully open-source solution, you can fork or self-host your own version in days without changing your habits and your code.
What about a vulnerability on their APIs? We believe it will take a lot more time to be discovered on a closed codebase than a public one.
With an open-source project you get more people to find, to report and possibly patch a bug.
Terminal-first experience.
What can we say? We are developers, we live in our terminal.
While a CLI is often quick to learn and fast to use, we can’t say the same thing of a web dashboard.
Plus a CLI is scriptable 🙌
Agnostic from programming languages
We share the views of the Heroku team and their 12factor publication. They prone a strict separation between your app and your config. We do too.
That’s why secrets should be injected as environment variables. No need for another dependency in your code to handle config files.