3 ms·

Thanks for the feedback. As you can see from that thread, EnvKey started out with per-developer pricing. The main issue is that we have some customers who use

Thanks for the feedback. As you can see from that thread, EnvKey started out with per-developer pricing. The main issue is that we have some customers who use EnvKey with hundreds of servers and only one or two users. This, of course, doesn't work out very well for us in terms of unit economics and pricing based on the value the service provides. That said, the usage caps are meant to be generous and not get in the way. If you're using EnvKey in a 'normal' way and not spinning up thousands of parallel processes or something along those lines, you'll be way, way under the limits on config requests. For connected servers, it's really just a question of how many server instances you're running that use EnvKey, which is something I would think you need to plan for anyway when it comes to hosting costs. I'm very open to adjusting these based on feedback if they are getting in the way / not matching up correctly with value. But as much as I'd prefer otherwise, I'm afraid there do need to be some sort of usage-based limits to make it work.

CaveTech 9y ago
I'm in a similar boat to the OP. We're near the boundary of your pricing between startup and traction, but the non linear jump (while being more common these days) is an immediate turn off. There's a pretty big difference between $240 and $1200 a year when it comes to discretionary spending.
- pw 9y ago
  I'd argue that if you're worried about a thousand dollars a year difference over the course of a year, you're not a customer worth having.
rjhacks 9y ago
I think the use case where the per-config-request pricing model could break is with serverless (like Lambda or Cloud Functions or ...). Secret management there is super important, and your solution looks great, except that what makes these platforms great for low-cost deployments is that they "scale to 0" (turn off your instances when there's no traffic), which means that each instance potentially lives just briefly. Since each start of each instance is a config request, that could in some cases become problematic. That said, at your lowest tier you could have ~20 moments of "booting a new instance" per hour. That's probably plenty for most cases, although you may find users for whom it isn't enough.
- danenania 9y ago
  Good point. What I'll say for now is that if anyone wants to use EnvKey with Lambda or Cloud Functions and is worried about this, feel free to reach out - dane@envkey.com. We'll make sure you're paying a reasonable price that reflects your usage level.

CaveTech 9y ago

I'm in a similar boat to the OP. We're near the boundary of your pricing between startup and traction, but the non linear jump (while being more common these days) is an immediate turn off. There's a pretty big difference between $240 and $1200 a year when it comes to discretionary spending.

pw 9y ago
I'd argue that if you're worried about a thousand dollars a year difference over the course of a year, you're not a customer worth having.

rjhacks 9y ago

I think the use case where the per-config-request pricing model could break is with serverless (like Lambda or Cloud Functions or ...). Secret management there is super important, and your solution looks great, except that what makes these platforms great for low-cost deployments is that they "scale to 0" (turn off your instances when there's no traffic), which means that each instance potentially lives just briefly. Since each start of each instance is a config request, that could in some cases become problematic. That said, at your lowest tier you could have ~20 moments of "booting a new instance" per hour. That's probably plenty for most cases, although you may find users for whom it isn't enough.

danenania 9y ago
Good point. What I'll say for now is that if anyone wants to use EnvKey with Lambda or Cloud Functions and is worried about this, feel free to reach out - dane@envkey.com. We'll make sure you're paying a reasonable price that reflects your usage level.