(no title)
psanchez | 3 years ago
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)
drcongo|3 years ago
danenania|3 years ago
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.
drcongo|3 years ago
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.
psanchez|3 years ago
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 -