Hacker News new | past | comments | ask | show | jobs | submit login
Launch HN: Infisical (YC W23) – Open-source secrets manager for developers
231 points by vmatsiiako on Feb 27, 2023 | hide | past | favorite | 121 comments
Hi HN, we’re the co-founders of Infisical (https://infisical.com), an open-source platform to sync application secrets and configs across your engineering team and infrastructure. We enable teams to store their secrets in a centralized location and distribute them anywhere from local development processes to staging/production environments.

Our Github is at https://github.com/infisical/infisical.

We previously worked at AWS, Figma, and another startup, where we frequently ran into problems dealing with secret management. For example, many companies used .env files to maintain their development secrets and struggled to keep secrets in sync amongst their teams (this routinely posed security and efficiency issues — secrets can get leaked or go missing). Some companies (especially bigger ones) used solutions like Vault which can be difficult to set up, maintain, and afford.

While secret managers exist, they’re imperfect for many reasons: open-source solutions are either too complicated, not comprehensive, not user-friendly, or a mix of all three; there are nicer closed-source solutions but with no self-hosted options available. The gap we see is to make something that’s simple, open-source, and powerful.

On the open-source front, our goal is to provide full transparency of our codebase and enable anyone in the community to build anything they want in an optimal secret management solution. If you need any feature or integration that we don’t yet support, you can post an issue about it or directly send in a PR to be reviewed immediately.

You can inject the right set of secrets for any environment into your application by using the Infisical CLI together with your application start command (e.g. infisical run -- npm run dev). This removes the need to use a .env file. Everything stays encrypted with encryption/decryption operations occurring on the client-side — under the hood, secrets are encrypted by vault keys for which there are multiple copies of vault keys encrypted under the public key of each member of a vault (ensuring only members of vaults can decrypt secrets pertaining to that vault locally). An alternative way is to use our Open API - though it’s a little complicated, and we’re working on adding SDKs to abstract away the cryptography.

Infisical integrates with staging and production cloud services like AWS, Vercel, GitHub Actions, and Circle CI. We also added support for integrations with Docker, Kubernetes, and Terraform. Infisical is now a central source of truth for secrets across the entire development cycle from development to production with new integration releases every week. One interesting thing is that, by default, our platform is end-to-end encrypted but users can opt out of that if they need to integrate with cloud platforms that require secrets to be sent in decrypted format (e.g. GitHub Actions, Vercel, Render). We’re the only solution that we know of that offers this E2EE-with opt-out ability.

Since our last Show HN (https://news.ycombinator.com/item?id=34510516), we’ve layered authentication with 2FA (more MFA options coming soon) and upgraded all private key encryption/decryption steps to involve a 256-bit protected key decrypted by another key generated via Argon2id KDF from the user’s password. We are starting the process of obtaining SOC2 and other security and compliance certifications. You can read more about our security here: https://infisical.com/docs/security/overview

Beyond this, we’ve added integrations with PM2, AWS Secrets Manager, AWS Parameter Store, Circle CI, Travis CI, GitLab CI/CD, Terraform and more. We’ve also redesigned the main dashboard and added more advanced organizational structure for secrets. Lastly, we have added role-based access control, and improved our Kubernetes operator: your clusters are now auto-redeployed when secrets in Infisical change. In the coming weeks and months, we plan to add features like secret rotation, improved audit logs, SDKs and alerts; as well as increase the range of our integrations; and continue fortifying platform security and stability.

We’ve launched this repo under the MIT license so any developer can use the platform. We don’t charge individual developers or small teams—all the integrations are fully available to everyone. We make money by charging a license fee for enterprise features as well as providing a hosted version and support.

If you found it interesting, you can see a demo video here: https://www.loom.com/share/9a8904c6ecc84d0899d53ee1f7a36385

We’d love for you to give Infisical a try (https://infisical.com) and provide any feedback. If you're interested, our code is available here: https://github.com/infisical/infisical. If we don’t have something, let us know and we’d be happy to build it for you. We look forward to your comments!




TIL that systemd has a credentials component: https://systemd.io/CREDENTIALS/


systemd can cut your hair and mow your lawn but you'll never remember the commands to take the blindfold off and see it


LOL


Thank you, 'cause I don't wanna do the wrap command thing they do. Besides that, this is a great idea.


Down to jam on your use-case!

The CLI "wrap command" is the main way of using Infisical at the moment and works for injecting secrets for local development as well as embedding into your Docker images if you use that; it definitely has pros and cons (a pro is not having to bundle any packages into your application code - in that sense, "dependency-less") but I can see it not being for everyone.

As mentioned we have an open API that we're working to make easier to use because E2EE ops for encrypting/decrypting secrets are not pleasant honestly to have to piece together yourself — because of this we have plans to release SDKs to abstract-away the cryptography (reading/writing secrets from/to Infisical would be one function call away).

What options would you want for interacting with a secret manager, just wondering?


This is actually not the only way to use Infisical (though it's probably the easiest one). You can also use our Open API and we are adding SDKs for the most popular languages in the next few weeks: https://infisical.com/docs/api-reference/overview/introducti....


What would your recommended approach be for distroless containers that don’t run a shell?


> All content that resides under any "ee/" directory of this repository, if such directories exists, are licensed under the license defined in "ee/LICENSE".

Man I really hate how the term "Open Source" is used nowadays.


We provide all the main functionality completely for free under the MIT license. What this means is that all the integrations (Docker, AWS, Vercel, Kubernetes, Terraform, etc) are available completely to everyone. Next to that, all the features related to secret sharing, and security are also available under MIT.

ee is only reserved for some features that are (mostly) needed by enterprises (e.g., audit logs, sso, advanced access controls). This helps us get the financial means to also maintain the free ope-source product better.


I'm not a fan of monorepos in general (though I admit tool support them better in many cases*) but making people download proprietary code makes them worse.

* Especially GitHub. Very opinionated in favor of monorepos.


Audit logging and SSO is pretty basic functionality that requires very little (many people would argue no) additional effort or cost to maintain on the development side.


One of the tenants pricing is you don't charge based on your development cost but based on the value to the customer. So, I don't think it's worth thinking about the complexity of a feature or the cost to maintain in when thinking about pricing besides making sure the maintenance cost is less than what you charge.

Generally, the reason all these companies go and charge for SSO and audit logging is because open core is a land and expand strategy. They offer a free tool that's useful for individual developers, and then when they start demanding enterprise features that means they are integrated into the enterprise and have the opportunity to extract value.


Surprisingly, audit logging has been deceivingly complex for us. There are many types of events (part of logs) triggered throughout the platform carrying different payloads/formats (e.g. events related to secrets, users, etc.). The variation in such events is increasing with the complexity of the product not to mention costs required to handle accumulating events. Last month, we served 14.2M+ secrets alone through the platform not counting other events — I hope this sheds more light on the audit logging side of things?

Re SSO: Totally get this one and I'm aware of the SSO tax — we're still figuring this one out but know currently that it's an absolute must for enterprises.


You know what you're definitely right about audit logging. It does seem like one of those "easy on the surface, will absolutely kill you in the details" sorts of things.


I know we (WorkOS) have already chatted with you about SSO, but reading this comment I'm realizing we should really also chat about Audit Logs too.

We recently built an entire product to make it insanely easy to offer enterprise-grade audit logs to your customers. Plus it includes strongly-typed event payload schemas and log streaming to 3rd-party SIEM vendors. Super fast to integrated with pay-as-you-go pricing based on volume. Vercel and others are using this.

https://workos.com/audit-logs

I think we have a shared Slack channel set up with Infisical so feel free to DM me there. You can also email me direct: [email protected]. (Same goes for anyone else on HN needing this stuff. :))


The cost to maintain and develop SSO has nothing to do with why it's priced the way it is (very few things in our industry are priced strictly according to cost). SSO costs extra because it's one of the most effective market segmentation tools: the people that require SSO in order to use things are generally (though not exclusively) price-insensitive.

This upsets people, but the larger companies that pay the SSO premium are subsidizing the smaller companies who don't care. I'd rather not pay an SSO tax either, but I'm even less excited about using tools from companies that are going to vanish because they're not generating revenue.


Actually I've never seen SAML based sso go completely smoothly. There is always some additional support there. That's not the reason everyone charges for SSO, but it is never plug and play.


We just spent about 3 months refactoring our audit logging. If it requires "no" additional effort, you can just fork the project and provide that "no" effort yourself.


I'm the founder of https://WorkOS.com ("Stripe for SSO") and I can definitely say it takes a lot of eng work to build and maintain. The complexity is fractal as you scale to more and more enterprise users with esoteric systems.


Big fans of WorkOS! Happy to be talking with your team about SSO options for Infisical :)

We built out all our OAuth2 integrations with other platforms (different from SSO but something relatable), so we have an idea of how much work it is to maintain these types of “integrations” and related services… Clearly enough to warrant entire solutions like WorkOS dedicated for this exact purpose.



In other words: this product is employing a pricing strategy that is overwhelmingly common in our industry (because it works).


And the industry is sick of it...? At least some vocal minority


Really strange thing to reply to this with. Did you find it just now and searched for "sso" on HN just to get a chance to randomly post it?


Why strange? That was the first thing that came to mind when I read “sso” as part of the “enterprise’ offering, and was not surprised to see that someone else linked the sso tax website


You're right. I misread the original post and also managed to do a double fail and misunderstand the SSO Wall of Shame as well. Sorry, mbarneyme!



Indeed! We are also planning to add the MIT-only copy of our repository that is going to remove all the ee licensed code.


As soon as I see a product is open core, I immediately start wondering what critical features are going to be proprietary. I don't see this information immediately on your website- is there a page where you outline what features you plan to keep proprietary?


Right now most of the features are available under the MIT license. For example, absolutely all the integrations, CLI, API, etc are available like that.

Basically, all the features that are needed by individuals and small teams will always stay completely free.

Some of the features that we are thinking to make proprietary are audit logs, sso, role-based access controls. Would love to hear your thoughts on this, because this is still in the very active stage of development!


What you decide is "needed by individuals and small teams" is not always what an individual or small team actually needs. This makes the open core model extremely difficult to get right (I am not sure I know any examples of anyone who has continued to do it right for very long).

For example, I would love SSO for my homeserver, so that I can share secrets with my family. I would guess that my family is a "small team", but many open core products don't open source SSO features. Many small actual businesses would prefer SSO too, as juggling multiple logins is as much a pain for a small team member as it is for a member of a big team.

I appreciate any open source contribution even if it is missing features. I understand it can be difficult to sell a product that is 100% open source.

Even when I am implementing something for a larger organization, I always prefer to specify open source over open core.

I end up very rarely adopting any open core product due to missing features- and when I do, I am often spending money re-implementing the closed source features, and thus the money isn't there to pay the company for support. I don't know how common this approach is, I just know a lot of open core products get skipped by me because of limitations.


Would you say GitLab didn't manage to keep it right over the period of many years?

I agree that it's very hard but that's also why we talk to our community and wee what they say about what features they need. I really happy hope that we can create a great open product for small teams and individuals over a long term too.


Actually, Gitlab used to be my go-to example of "Open Core done right", but now they have so many closed source features mixed in with open source features it is hard to use the open source product at all. I am either looking for a smaller product with fewer features anyway, or a product with more features (like maybe Gitlab tries to be) and the ones I want are the ones Gitlab happens to keep proprietary!

Ultimately, small teams often have the same challenges large teams have. I wish you great luck!

PS

At some point you might want to do product comparisons on you site- one of you competitors, Hashicorp does a pretty good job of outlining the similarities and differences as they see it with similiar options, I would suggest following their example. Even if Hashicorp ultimately adds a comparison with your product, having your own perspective is very helpful in making a quick comparison.


I will definitely echo everything said here. Gitlab used to be an amazing example of doing it right but nowadays looking at their release notes, they sprinkle in one or two free features while the vast majority are locked away.

They do sometimes give the peasants access to the features months or years later, but the majority of features are still locked away.


Main selling point for GitLab was the CI/CD couple years ago, and now it is so restricted that I just had to leave.

After they got that big funding when going public company, free features have been stripped and prices have increased. Same story as usual.


I definitely share the concerns/thoughts around open core and keeping too many features closed source here; it's a very difficult thing for companies to figure out what the right balance is for public/closed-source features. There's never a correct balance that satisfies everyone but the best we can do is deliberate which features would be more individual/team-oriented and which would be more enterprise-oriented to be charged.

In terms of Infisical, this is honestly something we're still figuring out as we're mapping out our roadmap ahead — We try to get feedback from our community in thinking about this since we all contribute to the codebase (also do feel free to suggest what you think would be appropriate).

And yea thanks for the suggestion regarding product comparisons with competitors. We have that on the TODO list in addition to other tasks all related to enriching product information like providing more granular product pricing breakdowns!


Hi. I'm also working on an E2E secrets manager. https://github.com/purton-tech/cloak

A few tips.

1. It looks like I'm able to do account enumeration on your login page. For a secure app you want to make sure this is not possible.

2. Your CSP https://csp-evaluator.withgoogle.com/ has unsafe-eval. I would lock that down.

3. Your app seems to be JS based, which is OK but it means you have a whole bunch of supply chain attacks on nodejs to worry about. You should only run the bare minimum JS on the frontend when dealing with encryption keys.

4. You're storing keys in local storage. There's a trick you can do, if you store an actual CrypoKey object instead of a string and set non extractable to true you can stop JS extracting private keys.

5. For key stretching looks like your using Argon2-browser. Actually browsers come with a built in with PBKDF2 that runs faster than a JS based argon. So I'm able to get 10 million iterations in a few seconds which is an NIST recommendation.

6. Some of your dependencies look like they are not maintained anymore. i.e. argon2-browser.

This is what I was able to find so far. Hope this helps.


Ack. Thanks for the points. Un-packing a few things:

3. Definitely — We're working to cut our dependencies in the coming months. Most existing dependencies (the backend at least - I focus more on this area) we stick to those widely used and those essential to the platform; there're also certain dependencies directly linked to integrations with third-party platforms (e.g. AWS, Octokit - GitHub, etc.).

4. We'll definitely take a look at this — This is on our immediate roadmap as well. We had a few ideas in mind related to a mix of components in browser-memory, session-storage, etc. as well but wanted to make sure we get it 100% right before deploying any changes - based on recommended practices like from Auth0. This article may be relevant: https://auth0.com/docs/secure/security-guidance/data-securit...

5. We actually did evaluate both PKDF2 and Argon2id options in addition to seeing what other secure platforms are doing. We found most to start out with PKDF2 but overtime to introduce support for Argon2id — Take Bitwarden and Dashlane as two examples of this; Bitwarden of which introduced it as of only a few months back. This article may help: https://soatok.blog/2022/12/29/what-we-do-in-the-etc-shadow-...

The choice of Argon2id KDF is sound and recommended; we have it with memory cost of 64MiB, ops cost of 3, and parallelism of 1.

6. argon2-browser is still used well and reliably throughout the ecosystem — take Bitwarden as the biggest example of a solution recently making the switch to use it.

Anyways, happy to move this discussion to email!


Check out https://socket.dev/ Been super impressed by their approach to identifying and securing codebases against supply chain attacks (and I believe they have a special deal for open source repos too!)


Just added it to my bookmarks — Will be checking it out thanks!

I wonder how this compares to Snyk, also in the area of securing against supply chain attacks.


Feedback on Cloak:

The javascript for the sign-up form doesn't activate the password-strength meter unless ther are keypresses in the primary (not verify) password box. This means when using Firefox auto-suggest strong password, we have to go type and then remove characters from the box to proceed.


Thanks. I'll take a look at that.


Thank you for pointing this out! Happy to take a look and discuss what you're building! I agree with some of these tips, but I think it's best to report them privately to [email protected]. We can then see with our team if these points are correct. Otherwise, this goes against responsible practices of security notifications and sounds more like an ad for your project.


You open-sourced your code - isn't this scrutiny exactly what you would want to achieve? Alternatively, I would expect these reports to be reported via your issues tracker.


Yup!

We appreciate feedback we can get across all aspects including security but employ a security policy of reporting any security concerns via email - this is pretty standard practice we've seen.


> employ a security policy of reporting any security concerns via email

You don't have a security.txt, https://infisical.com/docs/security/overview doesn't mention it and it's not on your FAQ, so I don't blame ianpurton for not finding it. You have a 'Report a vulnerability' issue template on GitHub (https://github.com/Infisical/infisical/security/advisories/n...) but then your readme points to a security policy which says to email: https://github.com/Infisical/infisical/security/policy


There are 3 different locations in the GitHub repo regarding the security policy: a SECURITY.md file containing instructions to report security vulnerabilities to [email protected] — this is employed in other open core repos like Strapi, PostHog, Chatwoot; a security policy on the sidebar that links to the SECURITY.md; and a security section in our README that also links to the SECURITY.md.

There's also an issue template for reporting vulnerabilities as well as you mentioned.

That said, we'll add info to the security page in our docs to contact us regarding vulnerabilities.

Thanks!


Standard practice is to do a full security audit before you onboard customers.


We're preparing to do a SOC2 with Vanta first followed by a security audit with some firm like Trail of Bits next.

We're fortifying the codebase every day and would expect this process to be complete in the next 2 quarters.


> the next 2 quarters

6 months? I'm not being sarcastic here - I'm not on the security or enterprise side of things, but this seems like a long way off for something like a secrets manager. Just out of curiosity, what would hold you back from doing this _prior_ to launching?


Getting certified is unfortunately not an overnight task … SOC2 alone will likely take months and that’s not yet factoring in the security audit as well. As much as we’d like to have it done ASAP, a lot of it is dependent on the length of the process and requirements to be met - that’s why my estimate is within the next 2 quarters (sooner the better).

As an open source company, we’ve basically “launched” since the moment we open sourced the codebase - it’s a constant iteration process for us and every week we release security updates as part of our roadmap. Security certifications and audits are something we’re starting to do in parallel at the moment whilst still being early in our journey (open sourced 3 months ago roughly).


I completely agree! I must say though, this is not fully dependent on us! SOC2 is a very lengthy process that also depends on auditors. This is one of our main priorities at the moment.


OK. I'll stop looking now. However if you do require a security review then I would be happy to oblige.


I took it as establishing credentials. They didn’t compare your project to their’s, and they offered helpful alternatives.


Wow, this comment is more than enough to make sure I never use your product.


> sounds more like an ad for your project

I feel like somehow your response is the opposite of an ad for your project.


Have you invested in automated testing since the last HN post?

Basic good practices like this being ignored does not give confidence in other aspects of the business and is a deal breaker for anything related to sensitive data like secrets.


We received a ton of feedback since our last HN post regarding many aspects of Infisical. We've had to prioritize user feedback in the last month, and one of the decisions we made together with our community was to move robust testing to March in order (see roadmap here: https://www.notion.so/infisical/be2d2585a6694e40889b03aef96e...) to address some other feedback first.

In terms of stability/security, I'm happy to say that we made HUGE improvements to platform-wide security, primarily revamping cryptography dealing with managing private key encryption/decryption operations (adding a protected key mechanism and Argon2id KDF - happy to elaborate more if needed) and adding MFA. Now that we're done with these updates, we'll be adding robust testing going into March and discussing it along with our community.


Hey there, I wanted to offer you some unsolicited advice. You're building a security product, so you have an uphill battle ahead of you. There is a reason security engineers get paid more than any other engineer, and why security companies can charge more -- because security is fraught with peril and just a single mistake can ruin your company/career.

You need to show that you are extremely competent at security -- more so than anyone I can hire myself. You also need to show that you care deeply about security.

For example, the fact that you lock SSO behind a paywall says that you don't care about security. Yes, SSO tends to be an enterprise ask, but it's also important for two person companies. I'd suggest changing at least that part to be 10+ SSO users or something like that, and make the first few free.

Also, your response to security reports in this thread is not what I'd want from a security company. Sure, the right way to report these things is via email, but you should still be grateful for the free security audit you got and approach that with a bit more tact.

At least make it look like you care more about security than revenue and adherence to policy.

Good luck, it looks like an interesting product, just make sure you don't turn users off with your security posture.


Thanks so much for this comment - very valuable insights.

RE security: 100% agree with everything you said. This is at the end of the day a security product. Even though we're very early, we've put a ton of thought into the security and especially the cryptography behind our product (e.g. we decided E2EE since the start) and intend on maximizing security posture in the coming months and years ahead — earning trust will definitely be an uphill battle but we hope to do it and have an optimal solution for everyone.

RE SSO: Initially, we started by exploring what other solutions on the market are doing about this and noticed SSO as an enterprise ask even for security products like Bitwarden. That said, I think you have a great point here that I'll discuss with the team: SSO doesn't have to be available/not available across plans but that it could be available across all plans and larger organizations would need to pay for it anyways on the basis of needing it for more users — this preserves the SSO benefit for individuals and small teams as well as enterprises.

PS: I'll work on doing a better job responding to security reports; I appreciate everyone's input a lot in this thread and hope to express that better over writing...


+1 to providing SSO to smaller plans, hard requirement for me.

I manage small teams and it would be a requirement for us, and if pricing for a few users is $14/month, normally enterprise is higher than that and an annual commitment, but you wouldn’t be able to get much budget out of me at this moment due to team size, but there is some there.

When choosing tools like this, I pick ones I can grow with so I don’t need to solve it again in the future, so while the team may be small, it can’t adopt it if I cant start from that point.


Mhm I'll definitely look over SSO and talk to the team about including it in the lower plans as it would definitely be useful for smaller teams as well.


> There is a reason security engineers get paid more than any other engineer

dubious claim


OK, aside from "open source", and assuming clients will be comparing paid enterprise to paid enterprise, how would you describe your value prop relative to Doppler?


2 main points:

- Infisical is by default end-to-end encrypted which means that we are not able to read you secrets (unless you give us explicit permissions for integrations that require it). This is not the case for many other products in the market, like Doppler.

- "Open source" is actually a big differentiator in this case, because people and companies can self-host Infisical on their own infrastructure. I can't really imagine JP Morgan storing their secrets on someone else's cloud. Many companies we talk to have very strict compliance restrictions, and this is where Infisical come in


Open source is a distribution strategy. Dont forget cyberark, thycotic et al in the enterprise space. They have super strong sales motion in the JP Morgans of the world.


Open source is a lot to unpack haha — There's a ton there but yea I think giving the ability for people to self-host the solution is a really important in our mission to increase access to secret management tools to all developers.

Infisical is already pretty easy to self-host but we want it to be even easier — Likely by introducing a 1-click deploy to Heroku/Digital Ocean for folks that need that.

And yea ack with the enterprise space solutions you mentioned. We've a long way to go as a secret manager but I have hopes that one day we'll get to a world-class product that's as good and better!


If being open source is such a big differentiator, why do you not reference it on your pricing page at all? https://infisical.com/pricing

I really wish companies would stop using open source as a growth hack.


It is actually mentioned on the pricing page! (in one of the FAQ questions)


I wouldn’t exactly consider a mention in passing on a “What is Infisical” to be exactly headlining the fact that it’s open source.


There is actually a question about self-hosted Infisical too. But I agree with you - we will do a better job for mentioning open source - we think this is VERY important, so this is definitely not our intention to hide it


How does getting permission make you “able” to read secrets? It seems like maybe you can read everyone’s secrets but you’re promising not to.


This has to do with how our underlying cryptography works; it's end-to-end encrypted by default with opt-out ability for integrations that need it. You'd have to manually login to Infisical and grant that permission but the platform itself would be unable to read your secrets otherwise.

Technical details: In Infisical, secrets are stored in vaults (we call them projects). They are encrypted symmetrically by vault keys for which there are multiple copies of vault keys encrypted under the public key of each vault member (your teammates). Vault members decrypt their copy of the vault key locally and use that to decrypt secrets (in browser or via CLI similar to platforms like 1Password and Bitwarden); this client-side decryption process makes it impossible for the platform itself to decrypt the secrets itself.

What is meant by users having the ability to give permission to Infisical to access/read secrets is to share a copy of the vault key by encrypting it under one of the public keys of Infisical — we employ an abstract concept of "bots" that have public-private key pairs assigned to each vault. When you share a copy of the vault key with Infisical (which can't happen without your explicit action), it grants Infisical the ability to access your secrets for integrations like Vercel, Render, GitHub, etc.


Very well explained, thank you.


Presumably the permissions switch is in the client rather than the server. It's true that you have to trust the client, but that's unavoidable.


Yeah that's correct.

The permissions switch can only be on the client because that's where sharing the vault key with Infisical by encrypting it under one of its public keys occurs.


Does anyone have suggestions for a truly free-as-in-freedom and open source secrets manager? I'm so tired of seeing these quasi-open source products that dual-license their source code and lock essential features like SSO behind an enterprise paywall. Every one of these VC-funded startups always eventually goes down the drain as their backers seek to recoup these investment dollars.


Hashicorp Vault?


previous discussion 2 months ago https://news.ycombinator.com/item?id=34055132


Not related but who or what tool designs these "startup pages"? I need it for my own work.


I designed it actually :)

Happy to help if you have any questions! It's a combination of Next.js + Tailwind + Figma. Oh, and we also use Framer Motion for animations on the landing page.

I also get a lot of inspiration on Dribbble.com


Some of it was sourced from posthog.com


Indeed! Especially the idea for the Slider part. We love PostHog


I thought there were a bunch of dead links on the page, but looking closer it's actually the "Star us on GitHub" banner extending some invisible element to the bottom of the page and blocking certain elements from being clicked on. (Firefox 111 on mac).


Thank you for pointing this out! Will try to fix this right now!


Just fixed this! Thank you!


Another issue, this one a blocker: Infiscal adds 2.2s to launch a process while I fully expected this delay to be incalculably small.

black:worker egor$ time infisical run /usr/bin/true

Injecting 6 Infisical secrets into your application process

real 0m2.269s


How does the Kubernetes integration work? Can we specify a infisical secret to reference inside of a Kubernetes secret manifest yaml? Thanks.


The Kubernetes integration allows you to periodically fetch secrets from an Infisical project and save them to a native Kubernetes secret. You simply specify the service token that should be used to retrieve the secrets from infisical and the operator handles the rest. Read more about it here! https://infisical.com/docs/integrations/platforms/kubernetes


Hey, congratulations on the launch. How does this compare to EnvKey[1]?

[1]: https://envkey.com


Thanks!

We're both in the same domain, open-source, and E2EE. Right off the bat, I'd say there are a few key observable differences:

- Infisical is open-source more-or-less from the get go and, as a testament to that, we've grown our community and contributors a lot (50+ now); Envkey was closed-source for a long time before deciding to open-source more recently.

- Infisical is E2EE with opt-out ability so user's can sync secrets directly to cloud platforms like Vercel, Render, GitHub, Netlify, etc. via their APIs; Envkey doesn't have this capability.

- Infisical's client is browser-based; Envkey's is an application you can download back.

Depending on your circumstance and needs, you may find pros and cons for going with either solution.

I will acknowledge that Envkey has been around for much longer, so it may have broader functionality in some respects (e.g. they have SDKs developed across most major languages that we have on our roadmap for the following quarters). Lastly, (small mention) I think that we do care about UI/UX more than a lot of other solutions in the market.

These are just some early thoughts; will add on as more come in.


Hey, CEO of EnvKey here. Congrats on the launch! Adding a few points to your points:

- The server portion of our v1 was closed source, but all client-side code has been open source all along. Now we're fully open source, as you say.

- Syncing to other platforms can be useful, but apart from breaking end-to-end encryption, it more or less guarantees that you're going to end up with consistency bugs. This is just the nature of failure modes in distributed systems. EnvKey's single source of truth architecture ensures consistency. Config and secrets are always pulled from EnvKey rather than being duplicated across platforms. Also, since all that is needed to integrate with any platform is to set a single environment variable, custom-built integrations are rarely needed (we do have a light-weight one for Heroku, but that's it).

- Browser-based is good for UX and convenience, but it nullifies most of the security benefits of end-to-end encryption. Browser-based end-to-end encryption doesn't protect against attackers or insider threats.

I'd also add that we care a lot about UI and UX as well, but we see our goal as making the best UI and UX that is possible while offering real, uncompromising end-to-end encryption. This does require some UX tradeoffs, but in our view, given the sensitivity the data involved, they are worth it.


Congrats to the Infisical Team! I was a first-time open source contributor thanks to this project and definitely could not have done that without the patience and guidance from the team.

Keep up the great work!


Thank you so much! It wouldn’t have been possible without your contribution :)


Interesting that this uses mongodb[1] - doesn't that mean the service is open under the mongodb license? Or does the managed service not use mongodb? Or did they (mongodb) go back to a more sane license? Or is the infisical Mongo image based off a fork?

[1] https://github.com/Infisical/infisical/blob/main/docker-comp...


Isn't MongoDB distributed under SSPL? I don't think there is any requirement unless you offer access to MongoDB directly, which Infiscal doesn't do.

> offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version


Indeed! We are currently using the main version of Mongo. We heard this criticism a lot, so we will be moving away to and/or adding other database options very soon.


What's the concern there? https://infisical.com/docs/contributing/overview#licensing emphasizes "Any third party components incorporated into our code are licensed under the original license provided by the applicable component owner."


They changed it fairly recently, you can read more about it here: https://www.scylladb.com/2018/10/22/the-dark-side-of-mongodb...


But how is that relevant to this particular project? This project is not offering them as a service


Why should someone use this when there are options within each Cloudprovider as well as Github and the like as well?


In many cases, your infrastructure may be sprawled from local development to cloud providers and CI/CD pipelines like you mention; you may have many environments each requiring their own set of secrets. This phenomenon is known technically as "secret sprawl" (see here for a fuller read: https://www.conjur.org/blog/what-is-secrets-sprawl-how-to-av...).

There's a lot of issues with secret sprawl but I think the relevant one to your specific question mentioning other cloud providers would be having missing secrets across infrastructure (you introduce a new secret to the codebase and forget to update it everywhere else, as well as communicate it or sync it through to other developers on your team) — applications crash, you lose time.

A big idea in secret management amongst others is the idea of *centralizing* your secret management in one place — update here, update everywhere. We help achieve that across your entire infrastructure and have a handy dandy CLI that also helps you inject secrets back into your programs (achieving secret management for local development with zero application dependencies) if you need that :D

I may be misinterpreting your question actually — Unless you mean why use Infisical versus other alternatives on cloud providers like AWS Secret Manager / Parameter Store, Azure Key Vault, etc?


They gave some reasons at the top.


This is awesome! So no more pbpaste | base64 | pbcopy with Kubernetes secrets? I won't miss base64 and yamls.


Indeed! You should check out out docs for Kubernetes here: https://infisical.com/docs/integrations/platforms/kubernetes


Minor bug: after execution of `infisical init` the resulting `.infisical.json` is executable on macOS:

black:worker egor$ ls -l .infisical.json -rwxr-xr-x 1 egor staff 122 Feb 28 11:19 .infisical.json*

(While minor, it's still a glaringly obvious thing, I wonder how could that have been missed by your devs)


Oh, I see that all json files stored in ~/.infisical have the executable bit set...

This may indicate that your developers have limited understanding of file permissions.


Also, check out roadmap and let us know if you have any suggestions: https://www.notion.so/infisical/be2d2585a6694e40889b03aef96e...


What does this remotely offer that Consul and Vault already do, in an extremely good, Highly-available way?


Website feedback:

Click to start video only works at the edges of the video, not the center (Firefox 110.0, MacOS)


This should work now! Thank you!


Fixing this!


It looks good! Look forward to more platforms, such as railway ,northflank


Thank you! Railway is almost ready! You can subscribe to updates here: https://github.com/Infisical/infisical/issues/271

Would you be able to open a GitHub issue for northflank? Thank you!


This is cool, LMK if / when you're hiring.


Wow, sounds good! I followed you on twitter, so let's stay in touch!


Awesome work! Congrats on the launch.


Thank you!


I don't see Terraform in your docs? Is it hidden away somewhere or not fully supported?


It seems like they haven't been merged yet. Check out the PR here: https://github.com/Infisical/infisical/pull/380

We also have a full provider under development here: https://github.com/asheliahut/infisical-provider-terraform


Great job team!!


[dead]




Consider applying for YC's W25 batch! Applications are open till Nov 12.

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

Search: