For some background, you can check out https://techcrunch.com/2018/02/27/envkey-wants-to-create-a-s... as well as a Show HN from when EnvKey first launched: https://news.ycombinator.com/item?id=15330757. The Show HN is what got EnvKey its first batch of production users, and I probably wouldn’t have gotten into YC without it. So thanks HN! I owe a hell of a lot to this community.

On where the idea came from: I had the first inklings at my last job. We were in the MVP stage, so we ended up with a bunch of separate apps and services as we experimented. These were split between CloudFoundry and Heroku, and we also had an in-house test server running CI for everything on TeamCity. Keeping stuff like API keys, puma server settings, and other environment-specific config in sync everywhere was a serious headache. Bugs and failed CI builds due to missing keys were common, and our Slack quickly filled up with requests for API keys and .env files. We knew this wasn’t secure, but there didn’t seem to be any solution out there that was worth the additional complexity it would introduce.

One day while wrangling with TeamCity build variables, I had the thought that this could all be so much easier. Why were we painstakingly copying big blocks of config from one place to another? It was like dealing with code pre-source control. And sure, our secrets were out of git, but was spraying them all over Slack and email any better? That night, I started typing out some notes for an 'Env Vars Locker' service that would use PGP and environment variables to solve this issue in a minimalistic way.

A bit later, I left that job to do something on my own. After a false start with a different idea, I decided that the 'Env Vars Locker' had potential. I did a round of problem interviews, and people were enthusiastic. It seemed like almost every team had this issue, and it only got worse as companies grew.

6 months later, I had a working beta and some early users. 6 months after that, EnvKey officially launched. Now we have many customers using it happily in production. It’s growing rapidly, and lots of new features are in the pipeline.

So that’s the backstory. Now for the good stuff: how it works.

With EnvKey, configuring any development or server environment becomes as simple as setting a single environment variable(ENVKEY=F4U4jGkZuo24zKxxgJsR-4f1g2w3VpHYpYC2x). It lets you edit configuration and set access levels for all your company’s apps, environments, and teams in one place with a user-friendly, cross-platform desktop ui.

It keeps developers and servers in sync securely and automatically so that people don’t resort to sharing secrets over email, Slack, git, spreadsheets, etc. (a serious security risk, even with 'development' secrets, since the line here is fuzzy). It also removes a whole class of config-related bugs, simplifies updates and secrets rotation, and prevents developers from interrupting each other or getting blocked when they don’t have the latest config.

Our servers are not trusted by any EnvKey client and cannot read or modify encrypted configuration (apart from deleting it). Public keys are verified by a web of trust during every crypto operation, and no third party gets access when you invite a new user to the system. The crypto is all vanilla OpenPGP, and all clients are fully open source. The security details are documented here: https://security.envkey.com

Apart from the cloud service, we're also working on an on-prem version and a hybrid option that will allow you to store the encrypted config in your own S3 account without having it ever touch our servers.

For reliability, we run a high availability Kubernetes cluster on AWS, and also back up encrypted config to S3 in a separate region on every update. If any of the client libraries can’t load from the server for any reason, they’ll fail over directly to S3 (you wouldn’t even notice).

Unlike other tools that require heavy lifting on the ops side and complex integrations, EnvKey typically takes less than 15 minutes to setup and integrate. With a line or two of code and an ENVKEY environment variable, all your config can be accessed just like local environment variables in your code.

With node, for example, it’s just:

$ npm install envkey —save

require ‘envkey’ // in main.js

Stripe.api_key = process.env.STRIPE_SECRET_KEY // this will always be in sync

Other languages (Ruby, Python, Go) work similarly, and there’s also a bash library called envkey-source that lets you set shell environment variables with a single line:

eval $(envkey-source)

This allows you to use EnvKey with any language. It also pairs well with Docker.

If you already use 12-factor or a similar approach, it’s extremely easy to switch. There’s an importer for bringing in your existing config that accepts bash KEY=VAL, json, or yaml format.

EnvKey is designed to be both simple and easy, and to make a previously messy and error-prone part of your system into something you hardly ever have to think about because it just works.

There are a lot of interesting possibilities for the future. Why are we dealing with API keys in the first place? I think this can all be abstracted over. Imagine that when a developer leaves a company, you click once to remove them, and then all the API keys and credentials they ever had access to are all automatically rotated behind the scenes. Or imagine integrating APIs like Stripe with your whole stack in one click. That’s the kind of thing that EnvKey enables and is why I believe this approach can have a huge impact. I hope you’ll give it a try and tell me what you think! I'm super interested to hear about your ideas and experiences in this area, since HN is obviously one of the places where people are most affected by these issues.