[HN Gopher] Show HN: Infisical - open-source secret management p...
       ___________________________________________________________________
        
       Show HN: Infisical - open-source secret management platform
        
       Hi HN, we're the founders of Infisical, the open source secret
       management platform - it provides an end-to-end set of tools to
       manage your secrets across your team and infrastructure
       (https://infisical.com/).  Excited to show you all the progress
       that we've made in the past few months after our Launch HN in
       February (https://news.ycombinator.com/item?id=34955699) and Show
       HN in December (https://news.ycombinator.com/item?id=34055132).
       During the previous Show HN and Launch HN, we received a ton of
       feedback which helped us improve Infisical. We've since released:
       - Secret scanning: a new toolset to block commits with hardcoded
       secrets and continuously monitor your code.  - Folders: Deeper
       organizational structure within projects to accommodate for
       microservice architectures and storage of more secret types like
       user API keys and OAuth tokens.  - Node and Python SDKs, Webhooks:
       More ways to integrate and start syncing secrets with Infisical
       across your infrastructure.  - Integrations with Terraform,
       Supabase, Railway, Checkly, Cloudflare Pages, Azure Key Vault,
       Laravel Forge, and more.  - Secret Referencing and Importing: to
       create a proper single source of truth.  - 1-click deployments to
       AWS EC2, Digital Ocean, Render, Fly.io: More ways to self-host
       Infisical on your own infrastructure.  In addition, the platform
       has become more stable and undergone a full-coverage penetration
       test; we've also begun the SOC 2 (Type II) certification process.
       Overall, we're really lucky to have support of the developer
       community, and, in fact, Infisical has gathered over 7k GitHub
       stars, and now processes over 200 million secrets per month for
       everyone from solo developers to public enterprises.  Our repo is
       published under the MIT license so any developer can use Infisical.
       Again, the goal is to not charge individual developers. We make
       money by charging a license fee for some enterprise features as
       well as providing a hosted version and support.  Check out
       Infisical Cloud (https://infisical.com/) or self-host Infisical on
       your own infrastructure (https://github.com/Infisical/infisical).
       We'd love to hear what you think!  We're excited to continue
       building Infisical, and keep shipping features for you. Please let
       us know if you have any thoughts, feedback, or feature suggestions!
        
       Author : vmatsiiako
       Score  : 103 points
       Date   : 2023-07-19 15:40 UTC (7 hours ago)
        
 (HTM) web link (infisical.com)
 (TXT) w3m dump (infisical.com)
        
       | lwhsiao wrote:
       | How does this compare with Hashicorp Vault?
        
         | vmatsiiako wrote:
         | 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.
        
           | zie wrote:
           | > 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! :)
        
       | microflash wrote:
       | The fact that there are no Java or Rust SDKs available makes this
       | a non-starter for me to even consider it.
        
         | vmatsiiako wrote:
         | 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
        
           | Alifatisk wrote:
           | Any plans on Ruby?
        
             | vmatsiiako wrote:
             | Yes! You can keep track of it via this issue:
             | https://github.com/Infisical/infisical/issues/435
        
           | candiddevmike wrote:
           | Hmmm
           | 
           | > The main goal is to create an all-in-one secret management
           | platform that targets developers
        
       | iLoveOncall wrote:
       | 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.
        
         | mousetree wrote:
         | There are tests:
         | https://github.com/Infisical/infisical/blob/main/backend/tes...
         | 
         | /s
        
       | sebmellen wrote:
       | 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?
        
         | vmatsiiako wrote:
         | 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.
        
           | sebmellen wrote:
           | Sweet. Thanks for the fast response.
        
       | aliasxneo wrote:
       | 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?
        
         | vmatsiiako wrote:
         | 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?
        
           | booi wrote:
           | If you need more than 10, it's usually because it's 1
           | environment per developer or 1 environment per branch
        
             | vmatsiiako wrote:
             | 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
        
       | ujnproduct wrote:
       | Love the landing page - beautiful!
        
         | vmatsiiako wrote:
         | Thank you :)
         | 
         | It's just a combination of tailwind and Next.js
        
       | Maidul98 wrote:
       | Hi HN. I'm one of the founders at Infisical. We'll be hanging out
       | in the comments in case you have any questions.
        
         | alchemist1e9 wrote:
         | Is docker use required? I prefer lxd/lxc.
        
           | vmatsiiako wrote:
           | We currently offer Docker images to keep the environment size
           | minimal. We might add more options in future
        
       | nevodavid10 wrote:
       | Great system, Amazing founders!
        
       | realitysballs wrote:
       | What's the business model? Is this FOSS or just OSS?
        
         | vmatsiiako wrote:
         | 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.
        
           | Zekio wrote:
           | wait, you need to pay to be able to use a yubi key for two
           | factor?
        
             | vmatsiiako wrote:
             | We don't have support for this yet. Would you say you think
             | this should be a free feature?
        
               | Zekio wrote:
               | I certainly wouldn't use the product if it isn't a free
               | feature
        
               | oldtownroad wrote:
               | 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.
        
               | vmatsiiako wrote:
               | 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.
        
       | majkinetor wrote:
       | How is this open source if we have limits with on premise
       | installations?
        
         | vmatsiiako wrote:
         | 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...
        
           | number6 wrote:
           | 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....
        
       | bilalq wrote:
       | I see you limit the number of projects on the team tier. What is
       | a "project" in your terms?
        
         | vmatsiiako wrote:
         | 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)
        
       | nodesocket wrote:
       | 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/
        
       | quickco wrote:
       | 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.
        
         | vmatsiiako wrote:
         | 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.
        
       | irf1 wrote:
       | 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
        
       ___________________________________________________________________
       (page generated 2023-07-19 23:01 UTC)