And still no tests in your codebase.

This is absolutely ridiculous when it has been brought up in every past Show HN that you've done.

I really really hope nobody is reckless enough to use a completely untested platform to manage secrets.

There are tests: https://github.com/Infisical/infisical/blob/main/backend/tes...

/s

... What did I just read? (But seriously, why would you ever have a file of what looks like at least some sort of tests but literally every line commented out?)

Because they theoretically worked at some point but now they do not.

You are obviously right but the question is still valid. They are using git and a deleted file is a one command away, so why keep the file but fully commented?

IMO this highlights further bad engineering culture.

I was wondering whether this project is safe to trust my secrets. Thanks for saving me time.

Besides, a challenge with secrets is hardware. Storing them on ordinary EC2 instances or else is insecure. That's why AWS Secrets, for example, use specialized hardware that are hardened for this use case.

> That's why AWS Secrets, for example, use specialized hardware that are hardened for this use case.

I'm curious what your source is for this claim. I presume when you say AWS Secrets that you're referring to AWS Secrets Manager?

Looks like a great platform, congrats!

Have you gotten feedback on the name, Infisical?

If a user is at a conference or on an online meeting and they mention your company to another user, they will likely have to spell the name out. Just hearing the name, it would be hard to know how to spell/search for it.

It is also not very memorable. A month later if I wanted to recall the name of your company I would likely have a bit of a hard time recalling the exact name.

In branding, simple is always better.

Yeah, we actually get feedback about this pretty often. At this point (because Infisical is used by many thousands of developers), it might hurt more in terms of recognition, SEO, etc. Some companies do it when they are much more advanced (Fb -> Meta, Square -> Block) but I think it requires a large marketing investment.

To make it easier to find us, we have purchased a number of other domains like http://inphysical.com/ and made them redirect to our main website.

If you have VC money secret or secrets.com might be worth it

How does this compare with Hashicorp Vault?

The main goal is to create an all-in-one secret management platform that targets developers and not just platform/security engineers (following the security shift left). Infisical is one platform where you can securely store your secrets, automatically sync them to 3rd party tools, continuously monitor code and prevent secret leaks, etc. We have more exciting features coming very soon.

On top of that, we heard over and over again that HCP Vault is too complicated for developers to set up and maintain. One of the goals of Infisical is to provide similar levels of security at a reduced learning curve. Because of that, we invested a lot of effort in the developer experience in order to make everything more intuitive for developers when compared to Vault.

You should try and let me know what you think.

> On top of that, we heard over and over again that HCP Vault is too complicated for developers to set up and maintain.

WOW! I'm shocked, it's a single go binary and it has been ridiculously easy (I've been running it in production for years now).

I've never tried your product, as I've been happily using vault for a long time now. If I ever have to move off of vault for some reason, I'll give your stuff a try though. If it's been designed to be easier than vault, it must do everything for me! :)

Er, installing Vault isn't the hard part; using it is. I suspect some of that is just complexity inherent to the problem space, though.

I guess? I mean sure the problem space can be a bit complicated, but I never had trouble using it either. Nobody @ $WORK has had issues either. shrugs

Very cool and congrats on the launch. Can you perhaps talk about pros/cons of using your Kubernetes operator vs 1Password Connect[1]? Seems like your operator would require writing some new CRDs where I believe 1Password Connect continues to use the existing kind: Secret. I believe it's possible to self-host Infisical server correct? Thus eliminating the external public requests and dependency on 1Password.

[1] https://developer.1password.com/docs/connect/

Thank you! And for one password you will need to create a kind called `OnePasswordItem` as described here https://github.com/1Password/onepassword-operator. This is similar to the `InfisicalSecret` you need to create with us https://infisical.com/docs/integrations/platforms/kubernetes

How is this open source if we have limits with on premise installations?

There is no limits for the usage of any open source feature. There are limits for some enterprise-level features. The fact that there are some features behind the license doesn't make the rest of the codebase less "open source"

Read this interesting blog by Sid from GitLab about this: https://opencoreventures.com/blog/2023-07-open-core-is-misun...

Yes what op means is Free Software. And this rationalizing shows that open source is not synonymously with Free Software.

Read this interesting post by Richard Stallmann:

https://www.gnu.org/philosophy/open-source-misses-the-point....

So is there a 5 user limit with on premise installation or not? The site seems to say so, and your comment just makes it more confusing.

There is not. This is only the limitation of the cloud version

So it isn’t all open source, but instead open core.

The offering by OP is a fairly common and accepted structure, and this seems like an unwarranted nitpick?

Another org with a similar offering is Elastic, who offer Elasticsearch as a "Free and Open, Distributed, RESTful Search Engine" per the Github repo. No-one is going to be complaining that they don't offer their full platform under an open source license.

Offering a self-hosted version of your core product with an appropriate license is standard fare.

If (correctly) calling it “Open Core” was inoffensive, and if “Open Core” is commonly accepted, why would you object to it, calling it an “unwarranted nitpick"?

The fact is that the Open Core model is quite controversial, and people should be made aware that Infisical uses it. But the announcement uses “Open Source” as some of the very first words of the announcement, and “Open Core” is not mentioned even once.

Because very few people use the term open core unless they are trying to be a pedant or nitpick, and your comment (and the grandparent) come off as trying to detract from the thread with a strawman.

The original post even explicitly explains what part of the offering is MIT licensed and what is commercial. So what is your point arguing semantics about open core?

People using Open Core don’t often use the term, since many of them are sleazebags who try to avoid using the term to try to hide the fact that they are using it, often prominently using the “Open Source” moniker, with various bad excuses when they are called out.

Nope. Open core vs open source is a big difference.

Hi HN. I’m one of the founders at Infisical. We’ll be hanging out in the comments in case you have any questions.

We currently offer Docker images to keep the environment size minimal. We might add more options in future

recently interviewed one of the founders :)

Tony discussed the team’s background, how Infisical got started & joined Y Combinator, the open core business model, hiring, college students contributing to open source and lots more. 10min highlights: https://youtube.com/watch?v=T9oFAxu_jAM

The fact that there are no Java or Rust SDKs available makes this a non-starter for me to even consider it.

Java SDK was actually already developed by one of our community members (Piyush Chhabra) and has to be reviewed: https://github.com/piyushchhabra/infisical-java

Rust SDK is coming soon too.

SDKs are not the most popular way of using Infisical though. You should look into our CLI (which most of the folks use) and API

Hmmm

> The main goal is to create an all-in-one secret management platform that targets developers

Any plans on Ruby?

Yes! You can keep track of it via this issue: https://github.com/Infisical/infisical/issues/435

Awesome

Love the landing page - beautiful!

Thank you :)

It's just a combination of tailwind and Next.js

This is really cool! We’re using SOPS right now which works alright, but it’s very easy to leak secrets and it’s a pain to sync updates as everything has to go through Git.

Can we use Infisical without the SDK? How would that work in a Node project?

Yes, definitely! If you're injecting secrets as environment variables into your apps, then you can just use the Infisical CLI (https://infisical.com/docs/cli/usage), it will automatically inject your secrets during local development, in CI/CD, some production envs, etc.

Sweet. Thanks for the fast response.

Nice work! This looks very promising. The only thing I would add is the difference in packages seems a bit weird:

- Five seems low for projects in the first tier

- Projects are unlimited in the second tier, but environments are not? Is that a technical limitation?

Thanks for sharing this! No, this is not a technical limitation. These are just the usage numbers that we saw from our users – in other words, it is very rare that teams need to have over 10 environments.

What is your use case for having more then 10 environments per project?

If you need more than 10, it's usually because it's 1 environment per developer or 1 environment per branch

For the use case of having 1 env per developer: you can use our secret override feature which allows users to branch out from "env_X" with their own secret values

For the use case of having each environment per branch: yes, you would need to have more than 10 environments

What’s the business model? Is this FOSS or just OSS?

It differs for open source and managed cloud:

1. For the managed Cloud product, it'a typical freemium model, where we have a pretty generous free tier, and you can upgrade if you need more features or higher limits than the free tier.

2. For the open source version, almost all the features (especially the ones that are needed by individual developers and small teams) are completely free with the exceptions of some managerial/compliance features (e.g., audit logs, potentially certain types of 2FA). These managerial features require a license. Some of these paid features are still under development. Plus, for the open source version, we also sell support packages to help with redeployments/maintenance/emergency situations.

wait, you need to pay to be able to use a yubi key for two factor?

We don't have support for this yet. Would you say you think this should be a free feature?

There’s a strong, widespread objection to hiding security features behind a paywall: https://sso.tax/

If 2fa is the only way you can differentiate in order to force enterprises to pay, it’s better to have a fee for security than to die because you can’t make money… but broadly, as a security company, you should aim for maximum security for every user.

If I were in your position, I’d start out by making security features available to everyone and then only if you feel you don’t have a choice would you put them behind a paywall — and at that point, you can grandfather existing customers in to these features for free.

Completely understand this take! 2FA is by far not the only differentiator we can make between enterprise/free users. We're definitely trying to make sure that the maximum security is available for every (free) user.

I certainly wouldn't use the product if it isn't a free feature

Be aware: It’s Open Core, not all Open Source.

I see you limit the number of projects on the team tier. What is a "project" in your terms?

It really depends on how users structure their secrets. Projects typically correspond to a single app. For example, APP_X can a project and it will have a set of environments (dev, staging, prod, etc) and within each environment they would be able to add folders for more depth like (frontend, backend, microservice_y, etc)

Great system, Amazing founders!