You raise a good point. EnvKey minimizes the number of secrets that you need to deal with, but you still do have to protect ENVKEYs (the access keys that EnvKey

You raise a good point. EnvKey minimizes the number of secrets that you need to deal with, but you still do have to protect ENVKEYs (the access keys that EnvKey generates). The idea here is to create a simple 'base layer' for access that can work with any host. Environment variables fit the bill nicely because you'll almost always have some way to set one, and access to these will generally be coupled to server-level access. That said, I'm definitely interested in adding other options for integration. For example, I'm currently working on a way to store encrypted configuration in S3 buckets you control instead of in EnvKey's cloud. With this approach, you could define bucket policies (for both development and production-level secrets), that would restrict access by IP or by security group. That way, even if an ENVKEY leaked, it couldn't be used outside of a privileged context. There are definitely other possibilities too. I'll look into the CNC server approach. Thanks!