Please note that as of August 1st, 2024, EnvKey Cloud is beginning a six month wind down. It will shut down on February 1st, 2025. New registrations are now disabled for EnvKey Cloud.
Learn more.

Comparing Configuration and Secrets Management ToolsRolling Your OwnAdvantages and Disadvantages Compared to EnvKey

Building It Yourself

When it comes to organizing configuration and protecting secrets for development and server environments, one option you might consider is building your own solution.

We'll treat this as distinct from simply ignoring configuration and secrets management where there is no over-arching plan or strategy.

Rather than simply ignoring the problem or leaving it to each developer to figure out for themselves, this entails designing and implementing a system that can meet your organization's engineering, infrastructure, and security needs.

⚖️Quick Compare

SecurityEasy IntegrationBug PreventionProductivityAvoid Lock-InOpen Source
Rolling Your Own ☠️ Poor ☠️☠️ Very Poor ☠️ Poor ☠️ Poor 💪💪 Very Strong 💪💪 Very Strong
EnvKey 💪💪 Very Strong 💪 Strong 💪💪 Very Strong 💪💪 Very Strong 💪 Strong 💪 Strong
Rolling Your OwnEnvKey
Security ☠️ Poor 💪💪 Very Strong
Easy Integration ☠️☠️ Very Poor 💪 Strong
Bug Prevention ☠️ Poor 💪💪 Very Strong
Productivity ☠️ Poor 💪💪 Very Strong
Avoid Lock-In 💪💪 Very Strong 💪 Strong
Open Source 💪💪 Very Strong 💪 Strong

Advantages

Can be specifically tailored to your tools and workflow. You'll know exactly what languages, tools, and platforms you need to integrate with (at least for now), so you can focus on those. And assuming you have the engineering bandwidth, your system can potentially fulfill bespoke internal needs better than a third party solution.

Reliance on external vendors can be avoided. This is less true if your solution involves stitching together third party services in some way, but at least in theory, you can do the whole thing in-house, assuming you're sufficiently motivated.

Disadvantages

It probably won't be secure. Cryptography and security are unforgiving disciplines that are rife with subtle pitfalls. You don't get points for a pretty good solution. Unless you know for sure that you can (rigorously) cover all the bases, you'll be leaving a door wide open. Half-baked secrets management systems are a go-to target for attackers.

It probably won't be reliable. Configuration and secrets management systems need to serve a large number of requests, and can easily become single-points-of-failure for critical services if they aren't achitected properly. Consistency is also essential: config values that aren't in sync can cause bugs, production outages, and other forms of chaos.

It probably won't be easy to work with. How much time are you really going to spend polishing the UX/DX of your configuration and secrets management system? Let's be honest: while it might fit into your workflow, it's also going to have plenty of warts, a barebones feature-set, not-enough-documentation, a steep learning curve for new devs, and a headache-quotient that grows over time as you integrate it with new apps and services.

It will probably take a long time to build. If you aren't convinced of that yet, I'd suggest re-reading the previous few bullet points again. Can you prove me wrong on every point and build a highly secure, highly reliable, strongly consistent, easy-to-use-and-integrate configuration and secrets management system? Maybe you can. Maybe. But one thing is certain: it won't be quick.

Conclusion

For the vast majority of organizations, EnvKey is simpler, faster, cheaper, more secure, and more effective than attempting to build a homegrown configuration and secrets management solution.

It could (perhaps) (potentially) (possibly) make sense if you have significant engineering resources available and have highly unique and complex requirements, but even then, you'd likely end up better off by using EnvKey as a base to start from, building whatever customizations you need on top, and devoting all the leftover engineering time to something that generates revenue instead.