Live data from Hacker News

Launch HN: EnvKey (YC W18) – Smart Configuration and Secrets Management

news.ycombinator.com

31–40 of 64 posts

Re: Launch HN: EnvKey (YC W18) – Smart Configuration and Secrets Management

#31

Earlier quoted context omitted.

Yes, it's definitely still on the radar. I have a basic version working, but ran into some complexity with Apache and PHP's request model. It doesn't make sense to run EnvKey in every PHP process (since they are per-request), so I'm thinking it needs to cache based on the Apache pid. I'm still working out the best way to accomplish this. Sorry for the delay!

Ah, no worries. I'm not sure if you're thinking it would be web server dependent, but NGINX is the bigger share of the market. (Ideally it wouldn't matter what the web server is though).

Good to know - as you can see, I don't have a lot of PHP experience.

If anyone knows of a good way to get a PHP process's parent server pid (regardless of what server it's running on), please let me know :)

Re: Launch HN: EnvKey (YC W18) – Smart Configuration and Secrets Management

#32

It looks really interesting, and I would definitely consider it (we're in the process of re-thinking our secret management solution. It works, and it's secure, but a bit clunky). We're a small bootstrapped company with only 4 developers currently. I have to say, though, that the pricing looks a bit intimidating. Not from the cost perspective, but just the complexity of it all. And you seem to penalize growth (there w…

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 w…

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.

Re: Launch HN: EnvKey (YC W18) – Smart Configuration and Secrets Management

#33

Earlier quoted context omitted.

Ah, no worries. I'm not sure if you're thinking it would be web server dependent, but NGINX is the bigger share of the market. (Ideally it wouldn't matter what the web server is though).

Good to know - as you can see, I don't have a lot of PHP experience. If anyone knows of a good way to get a PHP process's parent server pid (regardless of what server it's running on), please let me know :)

PHP has an execution model that's /really/ bad for per-process requests. Even attempting to grab the parent pid is probably not sufficient as you can have execution contexts with no parent (ex: running php from cron).

On linux you can get the master process through posix-getppid (http://php.net/manual/en/function.posix-getppid.php) but this won't work on windows and has the same limitations as above.

Have you thought about having a linux daemon/agent that runs in the background and keeps the ENV in sync?

Re: Launch HN: EnvKey (YC W18) – Smart Configuration and Secrets Management

#34

It looks really interesting, and I would definitely consider it (we're in the process of re-thinking our secret management solution. It works, and it's secure, but a bit clunky). We're a small bootstrapped company with only 4 developers currently. I have to say, though, that the pricing looks a bit intimidating. Not from the cost perspective, but just the complexity of it all. And you seem to penalize growth (there w…

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 w…

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.

Re: Launch HN: EnvKey (YC W18) – Smart Configuration and Secrets Management

#35
post #15

Earlier quoted context omitted.

I haven't personally used Azure key vault (or Azure in general), but as it looks comparable to AWS Parameter Store, here are a few potential benefits of EnvKey: - EnvKey is host-agnostic, so if you ever want to migrate to a different host, use an external CI tool, or even just bring up a quick script that relies on some configuration, that's trivial with EnvKey, whereas it might not be so easy with the Azure-specific…

Parameter Store is rather cumbersome and heavyweight for the kind of quick iteration you can do with EnvKey, and of course it's AWS-specific. I do use Parameter Store to "inject" the EnvKey into newly-booted EC2 instances, but then EnvKey takes over from there.

How is it cumbersome and heavyweight? If the app is already using AWS, it's trivial to start using the parameter store.

Re: Launch HN: EnvKey (YC W18) – Smart Configuration and Secrets Management

#36

It looks really interesting, and I would definitely consider it (we're in the process of re-thinking our secret management solution. It works, and it's secure, but a bit clunky). We're a small bootstrapped company with only 4 developers currently. I have to say, though, that the pricing looks a bit intimidating. Not from the cost perspective, but just the complexity of it all. And you seem to penalize growth (there w…

I don't get what the issue here is. Guess at which plan you'd need and go about your business. I'm sure they're reasonable about upgrading and/or paying for additional usage if you go over the limits. Even if they weren't, what's the risk here? That you'd end up owing a couple hundred extra dollars? If you're worried about that, you're probably not a customer they want. This sound like standard developer cheapness.

Re: Launch HN: EnvKey (YC W18) – Smart Configuration and Secrets Management

#37

Earlier quoted context omitted.

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 w…

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.

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.

Re: Launch HN: EnvKey (YC W18) – Smart Configuration and Secrets Management

#38
This looks really awesome, 'danenania. Secret management has been on my mind lately, and this really fits a sweet spot for what I'm looking for. I know things HashiCorp's Vault do basically the same thing, but Vault is complex enough that sometimes I barely understand exactly what it does. Good luck!

Re: Launch HN: EnvKey (YC W18) – Smart Configuration and Secrets Management

#39
post #34

Earlier quoted context omitted.

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 w…

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.…

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.

Re: Launch HN: EnvKey (YC W18) – Smart Configuration and Secrets Management

#40
post #36

It looks really interesting, and I would definitely consider it (we're in the process of re-thinking our secret management solution. It works, and it's secure, but a bit clunky). We're a small bootstrapped company with only 4 developers currently. I have to say, though, that the pricing looks a bit intimidating. Not from the cost perspective, but just the complexity of it all. And you seem to penalize growth (there w…

I don't get what the issue here is. Guess at which plan you'd need and go about your business. I'm sure they're reasonable about upgrading and/or paying for additional usage if you go over the limits. Even if they weren't, what's the risk here? That you'd end up owing a couple hundred extra dollars? If you're worried about that, you're probably not a customer they want. This sound like standard developer cheapness.

> I'm sure they're reasonable about upgrading and/or paying for additional usage if you go over the limits.

I certainly hope so, but we've been bitten by surcharges before when we had a mini-DoS on our system...

Besides that, there's a big element of trust here. I'm going to trust these guys with my most important secrets. I expect a trustworthy, transparent and simple solution that doesn't surprise me. Pricing is an element of that.

> This sound like standard developer cheapness.

I'm sorry, but this is just mean. I'm happy to pay, but I want to predict my costs. I understand usage-based pricing, but for a secret management system, I really don't see how this applies.

Sure, there might be outliers who might spin 1 billion micro-processes each connecting to their system, but I think it's the wrong approach to base your pricing on those. At least not until you're the scale of Amazon. Or even Digital Ocean.

I think I'm exactly the customer they want, but my 2 cents advice is to simplify pricing. Charge more. Fine. Just make it simple and clear.

Post reply on HN