61–67 of 67 posts
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?
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…
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?
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).
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…
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.
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…
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…
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.
Earlier quoted context omitted.
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…
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 ener…
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…
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…
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 -