Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Hey, I'm one of the founders of HashiCorp.

We'd like to make more of Vault Enterprise available to smaller companies with lower palatable price points. This will be reflected in certain features omitted as well as a lower level of support.

For now, please understand that our target _enterprise/commercial_ customer at the moment are Global 2000-esque companies. We currently have almost 10% of the global 2K as paying customers of Vault Enterprise. The features we've built along with the support you get reflect that (dedicated TAMs and so on). But we recognize that certain features of Vault Enterprise would be useful to smaller companies (replication and so forth).

To that end, we're currently planning some new packaging/pricing aimed at this type of user. I have no timelines on when we'd publish that, but its something we're actively doing now. This should make Vault Enterprise more affordable by smaller companies (think 5-figures/year instead of 6-figures/year).

Meanwhile, we're also making more "quality of life" features like auto-unseal available in Open Source. As we continue to add more features and value aimed directly at the Enterprise user, this lets us reevaluate and move more features into OSS and we have continued to do so throughout the life of Vault Enterprise. We hope this helps smaller companies adopt Vault successfully. And note that this is a great example of the model working: our success in Vault has funded growth in Vault staffing and that growth in Vault staffing has directly led to more OSS features and the growth in funding has led to our ability to more confidently make more features free. The community plays a huge role here, too. This is exactly how we intend for it to work!

One thing we learned rather painfully is that selling to the 4-figure vs 5-figure vs 6-figure vs. 7-figure/year customer is each a _very_ different company-building exercise. The expectations of the 7-figure customer (and we have a number of those) is dedicated TAMs, dedicated support reps, quarterly in-person meetings about the state of the install, high impact on the roadmap, and much much more. That of course requires a certain kind of staffing. Very often this staffing scales "down" to lower price points but very rarely does the staffing at lower price points scale "up" to higher price points.

As a company, we chose to go after the large enterprise deals first. This of course alienates some of the smaller deals since the large deals suck the air out of your org a bit. But as we've acquired more and more customers, grown, acquired more funding, etc. we're moving in that direction rapidly.

So, hopefully we'll get there soon! I'm sorry that you were quoted at a point that didn't work for us mutually and I'm glad you find an alternate solution that worked for you. For others in a similar position: we're working on it!



Thanks for this update. That explains a lot to me.

I'm a fan of pretty much everything you guys do, and like how you design and architect your products, but haven't yet crossed into the paid plans (haven't had the volume for it). And although a 5 figure sum is manageable for some of my customers (but still a tougher sell since they aren't technical), a six-figure sum just would never work since they aren't technical and just can't wrap their heads around why this is so important. Especially if they ask "can you guarantee I won't get hacked if I spend this money?" and I say "no, definitely not, but you'll be safer."

A SaaS model would work wonders for the next tier, the Fortune 5,000,000.


Hi Mitchell.

I had to kill a rollout of Vault at one billion dollar (revenue) company for the following reasons:

* the engineers doing the PoC could not/would not document how to operate it in production

* the managers did not take the unsealing responsibility seriously ("I'm in mgmt., don't call me on Sundays again.")

* our network was perceived as flaky.

Some cheap solutions are:

* provide some pre-written runbooks for administering Vault that people can cut-and-paste into their wiki

* provide some diagrams and scenarios for unsealing that can be adopted

* have the Vault server monitor and log network health (latency, bad packets, etc.)


sounds like you have problems in your org unrelated to vault.


> sounds like you have problems in your org unrelated to vault.

Unfortunately for engineers doing the deployment, Vault magnifies any weaknesses your organization already has. That's the nature of centralized key mgmt.

For example, I know one large company ended up using macros to unseal Vault to solve the key mgmt. problem I mentioned. In other words, the unseal keys are in plain text on the servers.

Probably happening more often than you would initially expect since nobody wants to drive down to the data center.

The remarkable thing with AWS KMS is that it's so seamless - it's idiot-proof compared to a self-hosted distributed system.


Obviously that's not ideal, but it's probably still more secure than using no secret management system at all.


Thank you for a very detailed and honest answer much better than marketing fluff that often get posted.


While we have you here, can you maybe shed a bit of light what is your commitment to Nomad these days? I hear you only talk about the k-word and Nomad is nowhere in the official communication. As someone who enjoys the philosophy and integration (with vault and consul) way more than k8s it makes me really concerned building on a product that might be abandoned soon.


Hey, I'm one of the co-founders of HashiCorp.

To keep it brief, we are more committed to Nomad today than before. The team has doubled in the last year, and we plan to grow further next year as well. Our goal has always been to build a simple, general purpose scheduler, that composes well with the rest of the HashiCorp ecosystem.

Kubernetes is an important ecosystem and a platform we tightly integrate with across our other products (Terraform, Consul, Vault). We've always believed that our tools would be "mixed and matched" with different technologies, and that pragmatically we should support the broadest range of integrations.

Nomad is an important piece of our ecosystem, and we have many open source users, enterprise customers, and our SaaS offerings are built on it. Rest assured, it's not going anywhere!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: