Launch HN: Infra.new (YC W23) – DevOps copilot with guardrails built in
55 points
0 comments
Do you have any plans to expand to non-US based clouds? This is an urgent concern these days.
Bug report: I went through the guest credits, signed up for an account via Google oAuth, and then got dumped to a screen which says "You don't have access to this chat".
It would be nice if this supported the AWS CDK.
Terraform is far too brittle of a tool/language to use LLMs IMO, even with guardrails. Naive changes like the kind LLMs tend to do can be catastrophic... I'm struggling to see the benefits of this product compared to more clickops-y infra LLM tools that just build out the infra without the GitHub shenanigans. I don't see a market where folks are savvy enough to understand the value of what you're doing here but unable to just have copilot or whatever generate all of this for them.
This looks like a good concept, what I'm more interested in is a "DevOps agent" that can analyze cloud resources and diagnose problems, suggest optimizations etc.The deployment part isn't a pain point, the maintenance and optimization is.
I think cool idea and I get why folks want more guardrails, but I always hit headaches with Terraform breaking stuff - you think better checks can really stop big issues or just make them easier to catch quicker?
Love seeing tools that prioritize infrastructure reliability. Well done!
As Ops/SRE/DevOps/Platform Engineer/Whatever person, I watched Loom and browsed the website. My initial thought is I recommend this to almost no one.Ops is a skill just like SQL/Backend/Frontend is. Most Devs here would recoil at thought of me writing Frontend with some LLM that swore up and down it would protect me from common SPA JS bugs/footguns I run into. I recoil at thought of vibing your way through Terraform/OpenTofu against Cloud Resources you don't understand and is loaded with footguns. Also Terraform/OpenTofu is riddled with footguns by itself. The fact 4 examples on their website is Kubernetes/Kubernetes/VM/Cloud Run is scary. If you need LLM to run Kubernetes, you shouldn't be running it. Cert Manager, External DNS and other things are complete grues that will eat you.What would I recommend, something that takes a container you create and runs it for you. GCP Cloud Run/Azure Web App/AWS Something/Heroku/Fly.io. (I work with GCP/Azure) Database should be Cloud Managed. If that's outside budget, then cheap VPS from company like Vultr/DigitalOcean with Docker Compose is my recommendation. Simple, easy to understand and easy to write simple GitHub action for. Once you need scaling, you can hire an Ops person and they can wrangle Terraform/Kubernetes.
The pricing makes me think too much. Tokens? Runners? I lose interest immediately on product pages when my brain goes into 'WTF is this going to cost me?' mode
Congrats on the launch.Here are my two cents, as I am very familiar with this space[1][2]The problem of trying to position your product as "an easy way to deploy on over GCP" or "an easier way to do K8s" is that your product is always limited by the potential of what the underlying platform directly offers. I know multiple K8s management startups (in the pre-LLM era) that failed because of this.You are not required to, but will be seduced to build 1:1 mapping to the concepts of the underlying systems. So, anyone using your product has to learn both the underlying platform (E.g., GCP) and your system. And the problem is that all of those concepts have been derived either directly or indirectly from AWS or K8s, both have a focus on SREs much more than software engineers.The second problem is that there are now two interfaces to change something - one is infra.new, and another is the underlying platform directly. Your system will have to catch the drift in deployment when someone goes and changes the underlying platform.The only major way to win is to have your deployment system, e.g., an alternative to vercel.com, Render.com, or https://railway.com. - Vercel - a deployment system for frontend engineers (that's my perception) - Render/Railway - a deployment system for backend software engineers (that's my perception) This approach is not guaranteed to succeed, but you are no longer limited to using the underlying platform's concepts. 1. - https://github.com/ashishb/gabo 2. - https://ashishb.net/programming/how-to-deploy-side-projects-as-web-services-for-free/
There are different personas in this space with different needs. It sounds like you're trying to reach the User who is currently doing ClickOps in cloud consoles to help set up their initial infrastructure and is subsequently getting lost.Your risks include: (1) if the User is not proficient with Terraform and similar tools, will they appreciate being given Terraform code that they don't know how to deal with, and the additional overhead compared to just, well, ClickOps'ing their way through cloud consoles, particularly since ClickOps is a fundamentally free product? (2) If the User is proficient with Terraform, won't they already have some ideas in mind about how to modularize their codebase for long-term maintainability? How do you address the "too many resources take too long to plan" problem?What you're describing is cool but I'm wondering who your target persona is, what value you provide above just ClickOps or running terraform plan locally, and whether that value solves enough of a pain point that people will be willing to pay?
Agreed this is a problem space that merits a robust solution (ie, emphasis on the guardrails and "rabbit hole" risks). Glad to see the founders' pedigree, and the rec to use in dev envs is a signal that increases trust, from my devops-adjacent pov. Bookmarked, I hope to get time to check this out before too long. In any case, good luck!