Show HN: EnvKey 2.0 – End-To-End Encrypted Environments (now open source)(v2.envkey.com)
v2.envkey.com
Show HN: EnvKey 2.0 – End-To-End Encrypted Environments (now open source)
https://v2.envkey.com/
66 comments
Initially, I was pretty thoroughly perplexed by what this actually did since all I did was click the original link and didn't even see this post text. I figured it out through mostly the 2017 link above. I have a pretty good idea now and see its value.
That being said, when looking at your actual website initially with no context, I couldn't really figure out what it did. My first instinct was to hit the "Docs" button.
The "Don't README" header and the just download my code and run it and figure out how it works later mantra with regard to an end-to-end encryption software (or software in general) was very off-putting to me. I actually wasn't very interested in figuring out what your software did at that point, as it just was flashing red-flag in my head. Was it malware? Was it really end-to-end encrypted?
Just a suggestion, you might want to reword some of that front landing page of the Docs page. I understand your wanting to convey that it "just works", but you might want to convey a bit better somehow what exactly what is just working in the first place, and do so in a way that isn't screaming "don't try to figure out how it's working". Maybe also advertise a bit more clearly that it's open source.
The whole "unless you really want to" is a little weird, too. Every end-to-end encryption software you use you should understand fully what encryption is being used, especially when targeting developers handling core secrets for major organizations or what have you.
That being said, when looking at your actual website initially with no context, I couldn't really figure out what it did. My first instinct was to hit the "Docs" button.
The "Don't README" header and the just download my code and run it and figure out how it works later mantra with regard to an end-to-end encryption software (or software in general) was very off-putting to me. I actually wasn't very interested in figuring out what your software did at that point, as it just was flashing red-flag in my head. Was it malware? Was it really end-to-end encrypted?
Just a suggestion, you might want to reword some of that front landing page of the Docs page. I understand your wanting to convey that it "just works", but you might want to convey a bit better somehow what exactly what is just working in the first place, and do so in a way that isn't screaming "don't try to figure out how it's working". Maybe also advertise a bit more clearly that it's open source.
The whole "unless you really want to" is a little weird, too. Every end-to-end encryption software you use you should understand fully what encryption is being used, especially when targeting developers handling core secrets for major organizations or what have you.
Thanks for your feedback! I'm sorry that the intro in the docs rubbed you the wrong way. I wanted to make sure people realize that it's not a complicated tool that requires a lot of setup or research to start using, and I guess to have a little fun too, but perhaps the tone is not quite right. I'll try to improve this.
Edit: what do you think now that I've removed the (probably misguided) playful language in the headings? https://docs-v2.envkey.com/docs Better?
Edit: what do you think now that I've removed the (probably misguided) playful language in the headings? https://docs-v2.envkey.com/docs Better?
Yeah that's a lot better. Don't get me wrong, I love playfulness, especially in documentation. It's just that before you even really know what a product is or does it seemed like it was worded like "don't even try to figure out what we are doing here and execute untrusted code" or something, haha.
I totally understood what you were trying to do, I just think if I interpreted it that way at first, others might as well. I at least had your other stuff to go off of to eventually get me to figure it out, whereas people encountering your page on the internet wouldn't. Was just trying to help :)
I totally understood what you were trying to do, I just think if I interpreted it that way at first, others might as well. I at least had your other stuff to go off of to eventually get me to figure it out, whereas people encountering your page on the internet wouldn't. Was just trying to help :)
Thanks! You're absolutely right that if you had that impression, others likely would as well, and there's not much to gain from it--the same information can be conveyed in a more fitting tone. Thanks again, I really appreciate it!
How does this compare to Doppler[1]?
Is there a way to handle the configuration in Terraform?
[1] https://www.doppler.com/
Is there a way to handle the configuration in Terraform?
[1] https://www.doppler.com/
I've met the Doppler founders and greatly respect them (even played some poker with them!). Doppler has great design and UX.
That said, I'd say the key difference is that EnvKey places much more emphasis on security and privacy. Doppler is cloud-hosted and doesn't use end-to-end encryption, so it requires that you trust them to keep your data safe and not make any mistakes in their data security, network security, who they hire, what sub-processors they trust, etc. In my (very biased) opinion, that is not sufficient protection for the most sensitive data.
Doppler also uses a web interface, which is great for convenience and UX, but leaves you vulnerable to compromised browser plugins, XSS, etc. I don't believe browsers are sufficiently secure currently for secrets management (if this changes, we'll add a web interface to EnvKey ASAP!).
There are real costs in terms of UX to end-to-end encryption. EnvKey tries to be as user-friendly as possible, but doesn't compromise on security or privacy. Doppler's design, as I understand it, leans more toward the other side of this tradeoff.
On Terraform--yes, it's easy to use EnvKey with Terraform. The general pattern for integrating EnvKey with any tool or platform is to set your ENVKEYs as secrets in whatever way the platform handles them, then expose each ENVKEY as an environment variable to your VMs, containers, or whatever else you're running. We'll write up a Terraform-specific guide soon to make it as easy as possible.
That said, I'd say the key difference is that EnvKey places much more emphasis on security and privacy. Doppler is cloud-hosted and doesn't use end-to-end encryption, so it requires that you trust them to keep your data safe and not make any mistakes in their data security, network security, who they hire, what sub-processors they trust, etc. In my (very biased) opinion, that is not sufficient protection for the most sensitive data.
Doppler also uses a web interface, which is great for convenience and UX, but leaves you vulnerable to compromised browser plugins, XSS, etc. I don't believe browsers are sufficiently secure currently for secrets management (if this changes, we'll add a web interface to EnvKey ASAP!).
There are real costs in terms of UX to end-to-end encryption. EnvKey tries to be as user-friendly as possible, but doesn't compromise on security or privacy. Doppler's design, as I understand it, leans more toward the other side of this tradeoff.
On Terraform--yes, it's easy to use EnvKey with Terraform. The general pattern for integrating EnvKey with any tool or platform is to set your ENVKEYs as secrets in whatever way the platform handles them, then expose each ENVKEY as an environment variable to your VMs, containers, or whatever else you're running. We'll write up a Terraform-specific guide soon to make it as easy as possible.
Co-founder/CTO of Doppler here. I'd agree that Doppler currently focuses very heavily on UX. We aim to fit into developer workflows, regardless of where devs run their code. This includes local development (macOS/Windows/Linux), CI/CD, Kubernetes, Vercel, and just about anywhere else. We've found that security tools that are difficult to use end up being worked around by developers, which ultimately decreases an org's security posture (see HashiCorp Vault). This does come with some tradeoffs- specifically that you must trust Doppler with your secrets, given our tokenization model[0].
We do recognize that the current security tradeoffs of Doppler aren't going to satisfy everyone. For Enterprises, we offer Enterprise Key Management (EKM), which allows orgs to encrypt their secrets using a cloud KMS. Of course, this still doesn't satisfy every concern. And so, for customers requiring additional security guarantees, stay tuned!
[0] https://docs.doppler.com/docs/security-fact-sheet
We do recognize that the current security tradeoffs of Doppler aren't going to satisfy everyone. For Enterprises, we offer Enterprise Key Management (EKM), which allows orgs to encrypt their secrets using a cloud KMS. Of course, this still doesn't satisfy every concern. And so, for customers requiring additional security guarantees, stay tuned!
[0] https://docs.doppler.com/docs/security-fact-sheet
I wonder why is it difficult to add an extra password on top of the access key.
What I mean is you can have another password or hash (separate to normal auth pass) which is only used to encrypt at browser and decrypt at the time of usage(through env load packages or your custom doppler command. This extra password is never sent or stored at doppler server.
> I don't believe browsers are sufficiently secure currently for secrets management
This is a super rare view, but one I truly appreciate. The risk of compromised browser plugins especially is vastly understated and underappreciated by... way too many "security" "experts".
This is a super rare view, but one I truly appreciate. The risk of compromised browser plugins especially is vastly understated and underappreciated by... way too many "security" "experts".
I don’t believe just about any platform we have now is really sufficiently secure for secrets management. Just as a compromised browser plugin can do a lot of damage, so too can a compromised desktop application (including its dependencies). The industry as a whole is not in a great place when it comes to protecting the integrity of our machines, especially developer workstations.
(And yes I know you probably know this better than most as a Sandstorm dev :)
(And yes I know you probably know this better than most as a Sandstorm dev :)
Interesting! You show a lot of examples where the server is created as a child of your EnvKey process. That kind of suggests you might encounter EnvKey being the PID 1 in a containerized application. Does EnvKey have a good "PID 1 discipline" -- in particular, reaping zombie processes?
Good question. envkey-source catches kill signals and then sends a SIGTERM on to the process it's running. The process then has a few seconds to handle the SIGTERM and clean up before it's forcefully killed with SIGKILL (the amount of time is configurable via an argument).
Does that answer your question?
Does that answer your question?
If your child processes spawn grandchild processes and then exit or otherwise die, and envkey-source is running as PID 1, then envkey-source will become the parent of those orphaned grandchild processes. When those orphans exit, envkey-source must check those process's exit status. Until then, those process IDs can't be reused, and the processes stick around as zombie processes.
In other words, PID 1 is special, because it may have child processes that it never created, and needs to be aware and handle them properly. Otherwise, you can end up leaking zombie processes.
It sounds like envkey-source isn't aware that it may adopt orphaned child processes. Killing them isn't the main issue. Checking their exit statuses is the main issue.
In other words, PID 1 is special, because it may have child processes that it never created, and needs to be aware and handle them properly. Otherwise, you can end up leaking zombie processes.
It sounds like envkey-source isn't aware that it may adopt orphaned child processes. Killing them isn't the main issue. Checking their exit statuses is the main issue.
Thanks, I'll have to look into this more deeply. Currently cleanup is being left to the watched process, but it sounds like more rigorous monitoring of grandchild processes is needed.
For some examples of what to do, see
https://github.com/Yelp/dumb-init
https://github.com/krallin/tini
https://github.com/Yelp/dumb-init
https://github.com/krallin/tini
Also, after you SIGTERM/SIGKILL your child processes, you check their exit statuses, right? Otherwise your child processes also sit around as zombie processes until you exit, the zombie orphans become children of init, and init properly "reaps" the zombies by checking their exit statuses.
The process management code lives here: https://github.com/envkey/envkey/blob/main/public/sdks/envke...
Basically, on unix systems, the command you pass in to envkey-source is run via:
exec.Command("sh", "-c", c)
(c is the command you passed as a string.)
Stdout/stderr is piped through, and .Wait() is called on the command. If envkey-source is in watch mode, it will send a SIGTERM when the environment is updated, then re-run the process once the initial process has died. I can verify that, for example, if a server listening on ports is restarted in this way, the process will die and the ports will be cleared before the new process is started (this has been well-tested).
Do you see a problem with this approach? We will prioritize making all this bulletproof.
Basically, on unix systems, the command you pass in to envkey-source is run via:
exec.Command("sh", "-c", c)
(c is the command you passed as a string.)
Stdout/stderr is piped through, and .Wait() is called on the command. If envkey-source is in watch mode, it will send a SIGTERM when the environment is updated, then re-run the process once the initial process has died. I can verify that, for example, if a server listening on ports is restarted in this way, the process will die and the ports will be cleared before the new process is started (this has been well-tested).
Do you see a problem with this approach? We will prioritize making all this bulletproof.
In the short term you could just tell people to use your 'eval' approach, and punt on the issue. :)
Looking at your code, what's missing is a SIGCHLD handler. Basically, your code doesn't know when one of its children dies. You're making an assumption that you know how many children you currently have, based on how many you spawned; but this is misleading due to PID1 semantics re: orphaned processes.
SIGCHLD lets you know that a child process has died. For each SIGCHLD received, your program should (must!) call 'waitpid' (or one of its related functions) to wait on the dead child process. You don't need to waitpid inside the signal handler; you just need to make sure that the counts of signals and waitpid calls eventually match up.
This is in a different language, but here's a nicely writen article about implementing PID1 in Rust:
https://www.fpcomplete.com/rust/pid1/
Someone in Go-land must have written a similar module. Your solution might be an 'import' away.
Looking at your code, what's missing is a SIGCHLD handler. Basically, your code doesn't know when one of its children dies. You're making an assumption that you know how many children you currently have, based on how many you spawned; but this is misleading due to PID1 semantics re: orphaned processes.
SIGCHLD lets you know that a child process has died. For each SIGCHLD received, your program should (must!) call 'waitpid' (or one of its related functions) to wait on the dead child process. You don't need to waitpid inside the signal handler; you just need to make sure that the counts of signals and waitpid calls eventually match up.
This is in a different language, but here's a nicely writen article about implementing PID1 in Rust:
https://www.fpcomplete.com/rust/pid1/
Someone in Go-land must have written a similar module. Your solution might be an 'import' away.
Thank you. This comment sums up why I love HN! We will improve this ASAP.
Is there somewhere I can ping you once we make the changes? Would be great to be sure we haven't missed anything in your estimation.
Edit: made an issue to track this: https://github.com/envkey/envkey/issues/3
Is there somewhere I can ping you once we make the changes? Would be great to be sure we haven't missed anything in your estimation.
Edit: made an issue to track this: https://github.com/envkey/envkey/issues/3
Sure. I've just subscribed to the ticket.
I'm not an expert on the topic. Like you said, we're on HN: there's probably five people here who have written PID1 for an actual Unix. :) But I'm happy to take a look.
I'm not an expert on the topic. Like you said, we're on HN: there's probably five people here who have written PID1 for an actual Unix. :) But I'm happy to take a look.
How is this tool different to Hashicorp's Vault?
Also, if I'm using "Enterprise Self Hosted", which means I am doing the hosting myself - am I not responsible for all the protection features you outlined there? If it's on my hardware, I'm doing the backups, patches, DDOS protection and so on?
I'm sorry if I sound blunt, but the pricing page looks like you tried to enlist as many buzzwords as possible to sound relevant. Auto-cluster mode sounds like PM2 cluster mode (PM2 being the supervisor tool).
There's many oddities in the pricing page, I won't list them all but I think you can see why I'm skeptic about your software. Vault does a great job dealing with secrets and is less ambiguous about what or how it does it.
Also, if I'm using "Enterprise Self Hosted", which means I am doing the hosting myself - am I not responsible for all the protection features you outlined there? If it's on my hardware, I'm doing the backups, patches, DDOS protection and so on?
I'm sorry if I sound blunt, but the pricing page looks like you tried to enlist as many buzzwords as possible to sound relevant. Auto-cluster mode sounds like PM2 cluster mode (PM2 being the supervisor tool).
There's many oddities in the pricing page, I won't list them all but I think you can see why I'm skeptic about your software. Vault does a great job dealing with secrets and is less ambiguous about what or how it does it.
Thanks for your feedback. Enterprise Self-Hosted runs in an AWS account that you control. It uses AWS Aurora and Fargate, along with a handful of other AWS supporting services. Auto-scaling, high availability, a private network, backups, patches, and DDOS protection are all built-in.
The goal is to make running self-hosted, production-ready EnvKey as easy and hands-off as possible. All the details on setup, deployment, and management are here:
https://docs-v2.envkey.com/docs/enterprise-self-hosted
The main differences with Vault are EnvKey's client-side end-to-end encryption, which doesn't trust the host API server under any circumstances, much simpler integration, much easier setup/maintenance for self-hosting (takes about an hour for a scalable, production-ready cluster), and many developer productivity features around managing environments, avoiding duplication, handling environment updates, access control, and a lot more.
All that said, I take your points and we will try to improve our pricing page.
The goal is to make running self-hosted, production-ready EnvKey as easy and hands-off as possible. All the details on setup, deployment, and management are here:
https://docs-v2.envkey.com/docs/enterprise-self-hosted
The main differences with Vault are EnvKey's client-side end-to-end encryption, which doesn't trust the host API server under any circumstances, much simpler integration, much easier setup/maintenance for self-hosting (takes about an hour for a scalable, production-ready cluster), and many developer productivity features around managing environments, avoiding duplication, handling environment updates, access control, and a lot more.
All that said, I take your points and we will try to improve our pricing page.
Why does client side encryption matter? explain it like I'm 5 please
If the host server is compromised, attackers still will not be able to access secrets.
Vault attempts to mitigate this with its 'seal' functionality, but in practice if an attacker gains access to a running Vault server, and/or the cloud provider account it's running in, there are many ways that secrets could be exposed.
EnvKey allows you to avoid trusting the host server, full stop.
Vault attempts to mitigate this with its 'seal' functionality, but in practice if an attacker gains access to a running Vault server, and/or the cloud provider account it's running in, there are many ways that secrets could be exposed.
EnvKey allows you to avoid trusting the host server, full stop.
In this regard envkey is much like 1password or lastpass, the server never knows the contents of your vault.
If cloud account is compromised, there are far worse implications that just being ble to access Vault's secrets and no, it's not true that there are "many" ways secrects could be exposed. That's precisely what Vault protects against.
Vault attempts to protect against host compromise scenarios, but it's a very hard problem. Ultimately, in order to do anything useful, Vault deals with plaintext values in memory, and that means that yes, there are ways for an attacker to get access.
Here's a good example: https://github.com/slingamn/vault-exfiltrate
The Vault docs include a list of 'hardening' steps for secure production usage. These are great steps to take, but each one represents a mistake that could be made. And because the Vault process is trusted with plaintext secrets, the stakes are high. Making a mistake could lead to a compromise.
With EnvKey, the host server is never sent secrets in plaintext. For defense in depth, we also follow best practices for hardening our networks. But I think we've seen with Okta and other incidents that despite best intentions, best efforts, and strong engineering, trusting the host server whatsoever just isn't good enough anymore.
Here's a good example: https://github.com/slingamn/vault-exfiltrate
The Vault docs include a list of 'hardening' steps for secure production usage. These are great steps to take, but each one represents a mistake that could be made. And because the Vault process is trusted with plaintext secrets, the stakes are high. Making a mistake could lead to a compromise.
With EnvKey, the host server is never sent secrets in plaintext. For defense in depth, we also follow best practices for hardening our networks. But I think we've seen with Okta and other incidents that despite best intentions, best efforts, and strong engineering, trusting the host server whatsoever just isn't good enough anymore.
Any plans for SOC or ISO27001 certification?
Yes, we plan to start the process soon for our Cloud service. In the meantime, our Enterprise Self-Hosted product runs in your own AWS account with no external dependencies, and is SOC/ISO27001 ready. Community Open Source could also fit the bill depending on your needs. You can find more details on our different offerings here:
https://v2.envkey.com/pricing
https://v2.envkey.com/pricing
Will take a look, thanks!
Looks interesting, is it a replacement for BitWarden too, or more focused on app environments (to set ENV vars)?
Yeah it's completely focused on app environments, so it's not a replacement for a password manager. That said, there's nothing stopping you from storing passwords in an EnvKey app and treating it as a very simple password manager. One benefit is that it would be very easy to manage your passwords programmatically in various ways if you had a need for that.
I have a few friends that run their own crypto nodes b/c they don't trust cloud providers (and their employees) to have access to their private keys (which may control millions of dollars).
Would this tool minimize the risk of an employee snapshots the disk and RAM of their machine?
Would this tool minimize the risk of an employee snapshots the disk and RAM of their machine?
Yes, EnvKey uses client-side end-to-end encryption and never sends secrets to the host server in plaintext (whether it's self-hosted or you use EnvKey Cloud). So there would be no way for a cloud provider employee (or an EnvKey employee) to get access from the server side. Even the names of your variables are encrypted and not accessible except on the client.
Except for a cold boot style attack right?
https://en.m.wikipedia.org/wiki/Cold_boot_attack
I’m assuming the client side code isn’t keeping the secrets in some kind of TPM right? ie anyone with root access to the server or the ability to dump the memory could pull them out.
https://en.m.wikipedia.org/wiki/Cold_boot_attack
I’m assuming the client side code isn’t keeping the secrets in some kind of TPM right? ie anyone with root access to the server or the ability to dump the memory could pull them out.
We need to distinguish between the server where EnvKey's API is running, which contains EnvKey's back-end logic, and 'client' servers (or user devices) that are connecting to EnvKey to fetch config for a particular app/environment. (It's possible I misunderstood the distinction the parent comment was getting at.)
EnvKey's API server has no access to secrets data. But you're right that a server pulling secrets via an ENVKEY access key would still have to expose those secrets in RAM to the process that needs them. We don't claim to protect user devices or connected servers from endpoint compromise.
We do offer some features to help mitigate this though:
- You can limit access to an ENVKEY to specific IPs or CIDR ranges.
- On a user device, secrets are periodically removed from RAM if they haven't been accessed recently.
- On a user device, only encrypted data is stored on disk, and the OS keychain is used on Mac and Windows.
- If an ENVKEY's access it cut off, envkey-source can immediately kill the process, making the secrets harder to access from RAM.
- Audit logs can help you track exactly what was exposed and when in the event of an incident.
- Access to secrets is 'pushed' as far down the stack as possible... so your secrets at least wouldn't be accessible in some cloud provider database--they would need to get access to the running process itself or the machine's RAM.
EnvKey's API server has no access to secrets data. But you're right that a server pulling secrets via an ENVKEY access key would still have to expose those secrets in RAM to the process that needs them. We don't claim to protect user devices or connected servers from endpoint compromise.
We do offer some features to help mitigate this though:
- You can limit access to an ENVKEY to specific IPs or CIDR ranges.
- On a user device, secrets are periodically removed from RAM if they haven't been accessed recently.
- On a user device, only encrypted data is stored on disk, and the OS keychain is used on Mac and Windows.
- If an ENVKEY's access it cut off, envkey-source can immediately kill the process, making the secrets harder to access from RAM.
- Audit logs can help you track exactly what was exposed and when in the event of an incident.
- Access to secrets is 'pushed' as far down the stack as possible... so your secrets at least wouldn't be accessible in some cloud provider database--they would need to get access to the running process itself or the machine's RAM.
> - On a user device, secrets are periodically removed from RAM if they haven't been accessed recently.
I looked at the ruby sdk code and it doesn't periodically remove them from RAM. Storing the ENVs in the `ENV` object makes me nervous, because its an easy target for supply attacks to dump the `ENV` to logs / remote servers.
I looked at the ruby sdk code and it doesn't periodically remove them from RAM. Storing the ENVs in the `ENV` object makes me nervous, because its an easy target for supply attacks to dump the `ENV` to logs / remote servers.
You're right--another distinction is needed here. For a human user using EnvKey, the EnvKey 'core-process' will run on their computer. Both the EnvKey UI and the CLI talk to this core process to fetch/display data or make updates. This is the process that will periodically evict secrets from RAM if they aren't used.
When loading a single environment via an ENVKEY access key, you're correct that there is no RAM eviction (in many cases this could break an app, unless it was designed to handle it).
If you don't want to use ENV/environment variables, you could also output your environment to a file and then pull it into your app and parse it (you can easily export to json, yaml, dotenv, or pam format):
$ es --dot-env > .env
$ es --json > .env.json
$ es --yaml > .env.yaml
$ es --pam > /etc/environment
When loading a single environment via an ENVKEY access key, you're correct that there is no RAM eviction (in many cases this could break an app, unless it was designed to handle it).
If you don't want to use ENV/environment variables, you could also output your environment to a file and then pull it into your app and parse it (you can easily export to json, yaml, dotenv, or pam format):
$ es --dot-env > .env
$ es --json > .env.json
$ es --yaml > .env.yaml
$ es --pam > /etc/environment
Those cmds write the variables unencrypted to disk?
Looking at the ruby sdk, I don't see any decryption libraries being used. I'd imagine a more secure solution would be to give the sdk the decryption key when the variables need to be decrypted, they are only decrypted by the process in RAM.
Since its ruby, and everything has access to everything in the process, it might make more sense to key management to exist in another process (thus limiting what access simple supply chain attacks have access to).
Looking at the ruby sdk, I don't see any decryption libraries being used. I'd imagine a more secure solution would be to give the sdk the decryption key when the variables need to be decrypted, they are only decrypted by the process in RAM.
Since its ruby, and everything has access to everything in the process, it might make more sense to key management to exist in another process (thus limiting what access simple supply chain attacks have access to).
Yes, those commands write the variables to a file, though you could also make a system call instead from within your app if you didn't want them in a file or environment variables.
The language SDKs (including ruby) wrap the envkey-source binary, which is where all the decryption and verification logic lives:
https://docs-v2.envkey.com/docs/envkey-source
There is an -m/--mem-cache flag that you can pass to envkey-source that makes it work just as you're describing. It keeps the variables in RAM and listens for updates, keeping them all up-to-date.
The language SDKs (including ruby) wrap the envkey-source binary, which is where all the decryption and verification logic lives:
https://docs-v2.envkey.com/docs/envkey-source
There is an -m/--mem-cache flag that you can pass to envkey-source that makes it work just as you're describing. It keeps the variables in RAM and listens for updates, keeping them all up-to-date.
+1, ideally, it should only decrypt (and fetch?) the when it needs to use the key. So 99% of the time, the key isn't sitting decrypted in memory.
Having to trigger a network call each time the key needs to be used (like to sign a transaction) isn't great though :-/.
Having to trigger a network call each time the key needs to be used (like to sign a transaction) isn't great though :-/.
From what I can see, public keys are checked by examining a signature chain which must terminate in the TrustedRoot.
This sounds more like a traditional PKI than a web of trust. Could you comment further on how this is a web of trust, and who is allowed to sign keys?
This sounds more like a traditional PKI than a web of trust. Could you comment further on how this is a web of trust, and who is allowed to sign keys?
In the client-side cryptography layer, a trusted keypair is able to sign a new public key, allowing that new key to be trusted by others in organization--this delegation of signing authority is what makes it a web of trust rather than a PKI.
Importantly, this is also restricted by the API server in the authorization layer. To invite a new user to an organization, authorize a device, or generate a new ENVKEY for an environment, a user must have appropriate permissions in the organization.
The trusted root is passed along, signed, through the invitation flow or ENVKEY generation, so that all keypairs in the organization agree on the trusted root of the organization, and can verify signature chains back to that root in order to trust a public key. Initially, the trusted root will be the keypair associated with the device that created the organization, but it can be revoked and replaced by another trusted keypair (again, given appropriate API permissions).
Importantly, this is also restricted by the API server in the authorization layer. To invite a new user to an organization, authorize a device, or generate a new ENVKEY for an environment, a user must have appropriate permissions in the organization.
The trusted root is passed along, signed, through the invitation flow or ENVKEY generation, so that all keypairs in the organization agree on the trusted root of the organization, and can verify signature chains back to that root in order to trust a public key. Initially, the trusted root will be the keypair associated with the device that created the organization, but it can be revoked and replaced by another trusted keypair (again, given appropriate API permissions).
Eyeing Business Cloud: How do you recommend to store the server key?
It depends on the platform you're using, but basically wherever you would store your secrets currently (API keys, database credentials, etc.) is where you should store your server ENVKEY.
Is it a replacement for ansible-vault too? What are the advantages of a solution involving a server?
For many platforms and tools (like Ansible) that offer some form of secrets management, instead of being a complete replacement, EnvKey piggy-backs on whatever is the standard secrets management approach, then adds a lot of functionality and security on top.
That's because EnvKey doesn't (and can't) completely eliminate the secrets you have to manage, but it does minimize them to a single secret (the ENVKEY) for each environment.
So now instead of setting a bunch of variables in ansible-vault, in Kubernetes secrets, in AWS secrets manager, etc. etc. for every environment that you run, you can just set a single ENVKEY in each of those tools, and then access/update/manage everything in a single place with all the productivity features and additional security that EnvKey offers.
That's because EnvKey doesn't (and can't) completely eliminate the secrets you have to manage, but it does minimize them to a single secret (the ENVKEY) for each environment.
So now instead of setting a bunch of variables in ansible-vault, in Kubernetes secrets, in AWS secrets manager, etc. etc. for every environment that you run, you can just set a single ENVKEY in each of those tools, and then access/update/manage everything in a single place with all the productivity features and additional security that EnvKey offers.
I'm a happy EnvKey customer since the end of 2018. After me and my team tried different solutions in the past (back in 2017 and 2018) to manage secrets on our infrastructure (we have a mix of kubernetes and VM's in diffeerent places) we read about EnvKey here on HN and we decided to give it a try. We fell in love with the product from minute 1. We use it for production and staging environments and it has worked like a charm from the start.
V1 is straightforward to setup, straighforward to use, and the best of it: it just works. Adapting all services to use it is very easy, even if you don't want to change the application itself, as long as uses environment variables, you can just launch it through envkey-source and it just works. I must say it has worked flawlessly for me for the last 3.5 years. So I'm very happy with it. In case anybody is considering to use it, I would encourage to give it a try. Honestly.
I cannot speak too much about the latest version (v2) yet, because we have not "migrated", although for what I've read so far, it looks even better than V1 as a product.
I think the reload functionality might be quite handy when running some services (although not a clue how well it will work in practice), and I always missed the option to have an API or command line to update secrets without opening the GUI. I mean, the GUI is great, but sometimes if you have to update a bunch of stuff (like SSL certificates) on a bunch of services, command line is just more convenient because you can script it or do it all at once.
I also appreciate the fact that it is moving to open-source because that means there is no "lock-in" to the company anymore, and even if the company fails, I can still use the product.
So, having said this, let me add a little of criticism on V2.
I don't like the fact that, as a customer, we have to migrate from V1 to V2. I mean, maybe I've got it wrong, but as far as I understood V1 is going end of life by the end of the year and if I want to continue using the product I have to migrate to V2. I guess that there is probably no way for EnvKey to migrate secrets from V1 to V2 transparently, so clients need to do this one-time migration, but that means changing all EnvKeys on all our services because the current ones will stop working, plus updating all libraries in all our services to V2. It is not like a difficult change to make, but we manage a lot of services and this looks like some sort of "bureaucracy" to go through to change to a major version.
I'm sure this is not a problem for new customers of EnvKey, but as 3.5 year-customer it is something unpleasant to do. Again, it might probably not take us long to do it, but I foresee spending some time with it, and I don't want to focus on a 3rdparty tool maintenance, I want to focus on my customer's problems. Some sort of backwards compatibility, or automatic migration would have been awesome. Dane, if you tell me the same "EnvKeys" will keep working on both V1 and V2, then I'll be amazed and happy, but so far I haven't read any communication about that, so I'm just guessing it won't.
The other thing that changed is pricing. As I mentioned before, I like the fact that it is now open source. Here is the thing, though, I'll be more than happy to continue paying for the service, because hosting it myself means having to spend time on it, which again, I don't want. I want to focus on the problems of my customers, so here comes the thing for me, now there are 4 tiers: OpenSource, Community Cloud (Free), Business Cloud (499/mo) and Enterprise Self-Hosted (1499/mo).
I've been paying 20/mo for the last 3.5 years, which was a nice price for our small team (even cheap). Going from paying 20/mo to 499/mo will make me think on self-hosting or looking for another solution. It exceeds the money I would like to spend on this. I miss something in the middle. I would happily continue paying 20/mo or even 50/mo, I would even evaluate paying something like 79/mo or even 99/mo at most but something higher than that does not justify keep using the service for me and my team (given our current size).
I'm not sure if I'm on the "free" tier anymore, because the pricing page mentions "user devices" and I don't know if that means user accounts (like the accounts using the EnvKey GUI App?) or what it exactly means... and same for "Server EnvKeys" does that mean each of the EnvKey projects or is that the amount of servers/services instances I have pulling secrets from EnvKey? Not clear to me. Finally, regarding the "Cloud Usage" credits, in the end, if I understood correctly this basically means X amount of storage and Y amount of bandwidth and Z amount of connections with different limitations. The problem I see with this is the same problem I see when I try to figure out pricing in AWS. I have no clue where I stand on those things, so I have no clue on whether that is too much or too little before using it. I can guess, but what does "active connections mean"? I guess this refers to the fact that the new tool with auto-reloading will use some sort of sockets/permanent connection, and for each of my service instances I would consume 1... but it makes it complex. This is probably a way for EnvKey to keep the costs controlled, but as a customer is makes things difficult to reason about in terms of pricing. Secrets, at least in my organization, are very small strings or very small files, so 100MB of storage data or 1GB of bandwidth (even if it was per month) seems like a lot, but probably you have different clients consuming different things, but the number of requests / number of connections...
Dane, if you are reading this, you certainly have better context than I do, but I believe that given a "reasonable" usage, EnvKey would be more appealing if it just charged on number of "seats" or maybe even on number of "projects" and be generous in everything else (cloud credits), even though I agree you should have some limitations. Personally, I think lowering the benefits on the "Free" tier and creating something in the middle between that one and the "Business Cloud (499/mo)" would make it more appealing to more teams. At least it would be more appealing to me/my team. Right now, without knowing if I'm going to be on the V2 free tier or on the Business tier (which is not worth the money for me), I would certainly explore the option of self-hosting and/or moving out to another service. Migrating to free to discover I'm on the business tier and then having to move away requires some extra effort that I'm not willing to do. In both cases your company is losing us as a paid client (even if a small one so far).
Again, as I initially said, it is an amazing product and I really like it, but I'm not sure my team will be using the paid version anymore due to the new pricing.
I hope my comment helps somehow to either bring new customers and/or for the pricing of EnvKey to evolve.
(edited it to clarify a couple of sentences)
V1 is straightforward to setup, straighforward to use, and the best of it: it just works. Adapting all services to use it is very easy, even if you don't want to change the application itself, as long as uses environment variables, you can just launch it through envkey-source and it just works. I must say it has worked flawlessly for me for the last 3.5 years. So I'm very happy with it. In case anybody is considering to use it, I would encourage to give it a try. Honestly.
I cannot speak too much about the latest version (v2) yet, because we have not "migrated", although for what I've read so far, it looks even better than V1 as a product.
I think the reload functionality might be quite handy when running some services (although not a clue how well it will work in practice), and I always missed the option to have an API or command line to update secrets without opening the GUI. I mean, the GUI is great, but sometimes if you have to update a bunch of stuff (like SSL certificates) on a bunch of services, command line is just more convenient because you can script it or do it all at once.
I also appreciate the fact that it is moving to open-source because that means there is no "lock-in" to the company anymore, and even if the company fails, I can still use the product.
So, having said this, let me add a little of criticism on V2.
I don't like the fact that, as a customer, we have to migrate from V1 to V2. I mean, maybe I've got it wrong, but as far as I understood V1 is going end of life by the end of the year and if I want to continue using the product I have to migrate to V2. I guess that there is probably no way for EnvKey to migrate secrets from V1 to V2 transparently, so clients need to do this one-time migration, but that means changing all EnvKeys on all our services because the current ones will stop working, plus updating all libraries in all our services to V2. It is not like a difficult change to make, but we manage a lot of services and this looks like some sort of "bureaucracy" to go through to change to a major version.
I'm sure this is not a problem for new customers of EnvKey, but as 3.5 year-customer it is something unpleasant to do. Again, it might probably not take us long to do it, but I foresee spending some time with it, and I don't want to focus on a 3rdparty tool maintenance, I want to focus on my customer's problems. Some sort of backwards compatibility, or automatic migration would have been awesome. Dane, if you tell me the same "EnvKeys" will keep working on both V1 and V2, then I'll be amazed and happy, but so far I haven't read any communication about that, so I'm just guessing it won't.
The other thing that changed is pricing. As I mentioned before, I like the fact that it is now open source. Here is the thing, though, I'll be more than happy to continue paying for the service, because hosting it myself means having to spend time on it, which again, I don't want. I want to focus on the problems of my customers, so here comes the thing for me, now there are 4 tiers: OpenSource, Community Cloud (Free), Business Cloud (499/mo) and Enterprise Self-Hosted (1499/mo).
I've been paying 20/mo for the last 3.5 years, which was a nice price for our small team (even cheap). Going from paying 20/mo to 499/mo will make me think on self-hosting or looking for another solution. It exceeds the money I would like to spend on this. I miss something in the middle. I would happily continue paying 20/mo or even 50/mo, I would even evaluate paying something like 79/mo or even 99/mo at most but something higher than that does not justify keep using the service for me and my team (given our current size).
I'm not sure if I'm on the "free" tier anymore, because the pricing page mentions "user devices" and I don't know if that means user accounts (like the accounts using the EnvKey GUI App?) or what it exactly means... and same for "Server EnvKeys" does that mean each of the EnvKey projects or is that the amount of servers/services instances I have pulling secrets from EnvKey? Not clear to me. Finally, regarding the "Cloud Usage" credits, in the end, if I understood correctly this basically means X amount of storage and Y amount of bandwidth and Z amount of connections with different limitations. The problem I see with this is the same problem I see when I try to figure out pricing in AWS. I have no clue where I stand on those things, so I have no clue on whether that is too much or too little before using it. I can guess, but what does "active connections mean"? I guess this refers to the fact that the new tool with auto-reloading will use some sort of sockets/permanent connection, and for each of my service instances I would consume 1... but it makes it complex. This is probably a way for EnvKey to keep the costs controlled, but as a customer is makes things difficult to reason about in terms of pricing. Secrets, at least in my organization, are very small strings or very small files, so 100MB of storage data or 1GB of bandwidth (even if it was per month) seems like a lot, but probably you have different clients consuming different things, but the number of requests / number of connections...
Dane, if you are reading this, you certainly have better context than I do, but I believe that given a "reasonable" usage, EnvKey would be more appealing if it just charged on number of "seats" or maybe even on number of "projects" and be generous in everything else (cloud credits), even though I agree you should have some limitations. Personally, I think lowering the benefits on the "Free" tier and creating something in the middle between that one and the "Business Cloud (499/mo)" would make it more appealing to more teams. At least it would be more appealing to me/my team. Right now, without knowing if I'm going to be on the V2 free tier or on the Business tier (which is not worth the money for me), I would certainly explore the option of self-hosting and/or moving out to another service. Migrating to free to discover I'm on the business tier and then having to move away requires some extra effort that I'm not willing to do. In both cases your company is losing us as a paid client (even if a small one so far).
Again, as I initially said, it is an amazing product and I really like it, but I'm not sure my team will be using the paid version anymore due to the new pricing.
I hope my comment helps somehow to either bring new customers and/or for the pricing of EnvKey to evolve.
(edited it to clarify a couple of sentences)
I agree with every single word of this. We're currently paying ~ $40 per month, been a customer since February 2018, and love the product. But we've built a load of internal tooling that uses EnvKey v1, made some small contributions to its library and ecosystem, and we're running it on maybe 80 servers (staging and production) so that migration to v2 looks like a pretty onerous task, and that pricing page is so opaque I have no idea whether or not at the end of the migration we're going to be looking at a 1400% price hike, which would feel like a pretty grim bait and switch.
Thanks so much for your comment and for being a long-time user of EnvKey. I really appreciate the time you took to write it and explain your thinking.
First I'll address the pricing concerns, then the migration from v1 to v2.
The intention with the v2 is that all customers currently paying $20/mo should fit very comfortably on the free Community Cloud tier and never have to worry about hitting usage limits. Given the limits, I believe this will be the case for typical usage patterns encompassing 90% of organizations on this tier, but if it turns out not to be, the limits will be adjusted upward. Does that help to address your concerns?
We'll also add some clarification on user devices and active connections to the pricing page. Those definitely do need to be explained more clearly. I'll write a quick summary here for now.
User devices: unlike v1 which has user-based auth and allows a user to sign into their account from any device, v2 uses device-based authorization. Now when you accept an invitation, just the computer you accept it on will be authorized. To sign in from a different computer, that computer needs to be authorized with a device invitation (these work just like user invitations). Pricing in the v2 is based on the number of authorized devices rather than the number of user accounts.
Active connections: yes, you got this right. Using the new watch/reload functionality of envkey-source maintains an open socket connection to be notified of changes. Signed in user devices that have EnvKey running also use a connection in order to receive organization updates immediately. So active connections = [number of signed in devices with EnvKey running] + [number of active envkey-source watchers].
Now onto the v1 > v2 migration. This was a tough decision. Due to major improvements to the underlying end-to-end encryption libraries and algorithms, v1 and v2 accounts are unfortunately not compatible with each other. I really wish the upgrade could be seamless, but I ended up deciding that faster, more scalable, and more secure encryption was worth the tradeoff in the long run. This process is automated to the extent that is possible given the need to generate new encryption keys in v2. Sadly that does still leave v1 customers with some work to do in order to move over, as you pointed out. I totally understand the frustration here, but am hopeful that the many improvements in v2 will outweigh the one-time cost of switching for the majority of customers.
First I'll address the pricing concerns, then the migration from v1 to v2.
The intention with the v2 is that all customers currently paying $20/mo should fit very comfortably on the free Community Cloud tier and never have to worry about hitting usage limits. Given the limits, I believe this will be the case for typical usage patterns encompassing 90% of organizations on this tier, but if it turns out not to be, the limits will be adjusted upward. Does that help to address your concerns?
We'll also add some clarification on user devices and active connections to the pricing page. Those definitely do need to be explained more clearly. I'll write a quick summary here for now.
User devices: unlike v1 which has user-based auth and allows a user to sign into their account from any device, v2 uses device-based authorization. Now when you accept an invitation, just the computer you accept it on will be authorized. To sign in from a different computer, that computer needs to be authorized with a device invitation (these work just like user invitations). Pricing in the v2 is based on the number of authorized devices rather than the number of user accounts.
Active connections: yes, you got this right. Using the new watch/reload functionality of envkey-source maintains an open socket connection to be notified of changes. Signed in user devices that have EnvKey running also use a connection in order to receive organization updates immediately. So active connections = [number of signed in devices with EnvKey running] + [number of active envkey-source watchers].
Now onto the v1 > v2 migration. This was a tough decision. Due to major improvements to the underlying end-to-end encryption libraries and algorithms, v1 and v2 accounts are unfortunately not compatible with each other. I really wish the upgrade could be seamless, but I ended up deciding that faster, more scalable, and more secure encryption was worth the tradeoff in the long run. This process is automated to the extent that is possible given the need to generate new encryption keys in v2. Sadly that does still leave v1 customers with some work to do in order to move over, as you pointed out. I totally understand the frustration here, but am hopeful that the many improvements in v2 will outweigh the one-time cost of switching for the majority of customers.
Hey Dane, thanks for the update, but reading this I'm fairly sure now that our monthly bill is going to go up by 1400% so that's not really a one-time cost - it's an absolutely huge increase for a very small agency. Having slept on this overnight now, I'm thinking I have two options - 1) spend a lot of time and energy switching over to EnvKey v2 and then pay 14 times as much for it, or 2) spend a lot of time and energy switching over to something else entirely and not pay 14 times as much for it. It seems pretty obvious which one we should go for.
Having put the time and energy into v1 and recommended it far and wide it's disappointing, but I guess we're not your target market any more.
Having put the time and energy into v1 and recommended it far and wide it's disappointing, but I guess we're not your target market any more.
I hear you! Thanks for posting your thoughts. I'm thinking this over, but it's likely some adjustments will be made.
Hi Dane, thanks for taking the time to reply and thanks for listening to our feedback.
It is still not clear to me what "40 server ENVKEYs" means. Is this different projects, or each ENVKEY on each of the projects? What counts towards this quota?
I've read a comment from you today (on another thread) about migrating from OpenPGP (RSA) in v1 to NaCl (EC) in v2. So I guess V2 encryption/decryption works faster on the gui/cli and security is stronger. I still would have loved as a customer to have EnvKey done this transparently to me. No idea on the internals, but something in the line of: whenever a customer updates any of its secrets, re-encrypt everything to use V2... but probably given existing architecture/design this is probably either too complex or unfeasible. Which makes me wonder... what would happen if an attack was found on curve25519 or certain type of attack was found? Just wondering, out of curiosity, if the current V2 design would support re-encrypting using a different algorithm (or even another key) in the client-side without other major changes (even if client has to re-encrypt messages from the CLI/GUI). Just wondering.
I've decided I'm going to give it a try to re-import all keys in order to see how a migration would look like and see if I'm hitting any limits beyond the free tier, but if I am, even though I would pay 2-3x what I'm paying now, I think either I'll move to the open-source version or look for something else. In any case I'll drop you an e-mail with my experience.
Coming back to the pricing discussion, as a customer I still like V1 pricing for its simplicity/clarity. You pay per users and that's the end of it. I believe a combination of nº of projects and nº of users might be the way to go for your product, because as a customer is easy to understand and easy to predict, and even if there is a fixed price per user/project then the more projects you add, the more you pay, incrementally... but this is just a thought. Same with the limits... I mean, it would be nice to say, here are the limits, if you surpass them regularly, they would be charged by X amounts.. which is also incremental.
Anyway, thanks for mentioning in another comment you are considering some adjustments. I mean, as drcongo said, maybe we are not your target anymore, maybe we are just a vocal minority, you are the one with all the info anyway. The new pricing might be the right thing for your company, not a clue, although I honestly think there can be something in the middle that even if it gets you marginarlly more money/users at the beginning, might allow your customers to stay and grow as their company grows, which will help you grow as they grow. Final though, the current jump in princing from the free tier to the business tier makes me hesitant to even use the free tier.
And again, the product itself is amazing and I am very happy with it, no complaints at all with it.
- minor edits for clarity -
It is still not clear to me what "40 server ENVKEYs" means. Is this different projects, or each ENVKEY on each of the projects? What counts towards this quota?
I've read a comment from you today (on another thread) about migrating from OpenPGP (RSA) in v1 to NaCl (EC) in v2. So I guess V2 encryption/decryption works faster on the gui/cli and security is stronger. I still would have loved as a customer to have EnvKey done this transparently to me. No idea on the internals, but something in the line of: whenever a customer updates any of its secrets, re-encrypt everything to use V2... but probably given existing architecture/design this is probably either too complex or unfeasible. Which makes me wonder... what would happen if an attack was found on curve25519 or certain type of attack was found? Just wondering, out of curiosity, if the current V2 design would support re-encrypting using a different algorithm (or even another key) in the client-side without other major changes (even if client has to re-encrypt messages from the CLI/GUI). Just wondering.
I've decided I'm going to give it a try to re-import all keys in order to see how a migration would look like and see if I'm hitting any limits beyond the free tier, but if I am, even though I would pay 2-3x what I'm paying now, I think either I'll move to the open-source version or look for something else. In any case I'll drop you an e-mail with my experience.
Coming back to the pricing discussion, as a customer I still like V1 pricing for its simplicity/clarity. You pay per users and that's the end of it. I believe a combination of nº of projects and nº of users might be the way to go for your product, because as a customer is easy to understand and easy to predict, and even if there is a fixed price per user/project then the more projects you add, the more you pay, incrementally... but this is just a thought. Same with the limits... I mean, it would be nice to say, here are the limits, if you surpass them regularly, they would be charged by X amounts.. which is also incremental.
Anyway, thanks for mentioning in another comment you are considering some adjustments. I mean, as drcongo said, maybe we are not your target anymore, maybe we are just a vocal minority, you are the one with all the info anyway. The new pricing might be the right thing for your company, not a clue, although I honestly think there can be something in the middle that even if it gets you marginarlly more money/users at the beginning, might allow your customers to stay and grow as their company grows, which will help you grow as they grow. Final though, the current jump in princing from the free tier to the business tier makes me hesitant to even use the free tier.
And again, the product itself is amazing and I am very happy with it, no complaints at all with it.
- minor edits for clarity -
How do you handle a situation where the attacker gains access to decrypted set of secrets and steals them? Can you prevent this scenario in any way, or does single hacked admin results in a complete compromise with no way to recover?
If an attacker gains access to your app's process where the secrets are in RAM, there's not much protection we can offer, since ultimately the variables need to live in plaintext somewhere in order to be used. But recovering is a lot easier/faster since you can track down exactly what was exposed with audit logs and rotate compromised credentials in one place instead of needing to track them down across many devices/servers.
For a human user, there are multiple layers of security: email/SSO authentication, a per-device encryption key (stored in the OS credential store on Mac/Windows), and, optionally: a passphrase that locks the per-device encryption key and a lockout that clears RAM and locks EnvKey on the device after a specified time period until the user inputs their passphrase. EnvKey organization owners can require that passphrases/lockouts be set for all org members.
For a human user, there are multiple layers of security: email/SSO authentication, a per-device encryption key (stored in the OS credential store on Mac/Windows), and, optionally: a passphrase that locks the per-device encryption key and a lockout that clears RAM and locks EnvKey on the device after a specified time period until the user inputs their passphrase. EnvKey organization owners can require that passphrases/lockouts be set for all org members.
How do I use this in docker ? any references.
Here's a docker guide: https://docs-v2.envkey.com/docs/docker
All of the links to the language sdks are broken:
https://docs-v2.envkey.com/docs/language-sdks
https://docs-v2.envkey.com/docs/language-sdks
Oops, just fixed those. Thanks!
[deleted]
this seems like an awesome project! would like to learn more, but is it just me or is the link to the security overview broken?
Sorry about that! Just fixed it.
I'm so happy to finally show you all this release after years of hard work. I posted the first version of EnvKey to HN back in 2017 (https://news.ycombinator.com/item?id=15330757), then went through YC in W18 (https://news.ycombinator.com/item?id=16569534).
EnvKey is an end-to-end encrypted configuration and secrets manager. It protects your organization's API keys, encryption keys, credentials, and other secrets, and makes it easy to run servers, scripts, tests, and everything else with the latest config. It also helps you avoid duplication in your configuration, react to environment updates in real-time, resolve conflicts smoothly, and a lot more.
You get an intuitive, spreadsheet-like UI for managing environments, along with a developer-friendly CLI that does almost anything the UI can. Running any program in any language with the latest environment variables is as simple as:
You can use the `es` alias to type less:
You can automatically reload a process whenever there's a change using the -w flag:
To avoid downtime on reloads, add the --rolling flag to reload gradually across all connected processes:
You can run custom logic when there's a change instead of restarting:
Or run something only when there's a change:
You can pass command line arguments from EnvKey variables (just wrap your command in single quotes):
You can export your environment to the current shell:
Or auto-load the latest environment in any EnvKey-enabled directory (like direnv):
EnvKey is now open source under the MIT license and can be self-hosted. Our Cloud and Enterprise Self-Hosted products also include commercially licensed server-side extensions for auto-scaling, highly available infrastructure and advanced user management. Cloud is free for up to 20 user devices and 40 server keys.
EnvKey's client-side end-to-end encryption is built with the NaCl crypto library. Whether you use EnvKey Cloud or host EnvKey yourself, no configuration or secrets are ever sent to the host running EnvKey in plaintext. Public keys are verified by a web of trust. Invitations are verified out-of-band. Secrets are never accessed through a web browser. More details on security and encryption can be found here: https://docs-v2.envkey.com/docs/security
Let me know what you think! Thanks!