Replies: 1 comment
-
Thanks for opening up this discussion. Infisical is a bit different from other self-hostable tools in that there is a real need for the product to be hosted easily. This is for a variety of reasons for wanting to self host Infisical, including meeting compliance. As a result, while it may seem a bit cumbersome to deploy Infisical, we are continuing to improve the self-hosting side of Infisical. In fact, just this week, we have released a highly optimized version of Infisical that can be deployed with just a single docker image. You can deploy Infisical on services like Google Cloud Run, Render, Fly.io, and many others within just 5-10 minutes. S3 is a great idea, and the team is aware that expanding the persistent layer is a major factor in improving the self-hostable experience. We have plans to add PostgreSQL as a backend, and many more options will come in the future. Check out this document to deploy Infisical with a single docker image: https://infisical.com/docs/self-hosting/deployment-options/standalone-infisical |
Beta Was this translation helpful? Give feedback.
-
We're looking at Infisical. It's a nice tool! 🎉
What we like about it is that:
I know many open-source SaaS companies want to make deployment a hassle, to encourage paid cloud.
However, the current self-host story is somewhat complicated. Do you really need MongoDB and Redis? Nginx?
Ideally a simple docker container (stateless) + some simple storage like S3 or Sqlite/Litestream should be enough. Redis could be optional, for higher performance needs.
But for our production use-case, it's just kwstorage and traffic volumes will be super-low. Just writing via UI and reading a few values on new deploys.
S3 storage would also enable simple/dumb replication via S3 region replication, for an easy multi-region setup.
Asides
I'd consider the Business Source License. That way, you have fewer incentives to keep functionality out of the self-hosted version, but can still reasonably monetize.
You should push the dual self-host + cloud for developers story more. I think that's a very compelling benefit with your offering, an area where several of your competitors will have a harder time (because they aren't open-source).
Benefit with this is that we get dev/prod parity (CLI tools etc), without the security risks of using hosted SaaS for secrets.
Several of your integrations requires dropping E2EE. I can see why, because it's easy. But I think you should have a higher bar. E.g. AWS param store. You could also sync the encrypted secrets, and we could read them using your CLI tool (decrypt on the client).
Beta Was this translation helpful? Give feedback.
All reactions