Launch HN: Infra.new (YC W23) – DevOps copilot with guardrails built in
23 comments
·April 22, 2025stackskipton
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.
chrisweekly
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!
TankeJosh
Thank you for the feedback! Would love to hear your thoughts when you have a chance to try it.
candiddevmike
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.
calebtv
Yeah Terraform does have some sharp edges, but we chose it because it's the most widely used IaC language and lets you review any changes the agent wants to make before actually applying them in your cloud. One issue with an agent making click-ops changes is there's little to no visibility into what actually changed other than going through the console to verify it yourself. Terraform also lets you do more static checks like cost estimates and policy enforcement before deploying the changes.
candiddevmike
So there was originally BuildFlow[0], then LaunchFlow[1], and now infra.new? How many pivots are you folks going to do? What happened to all the customers you had on these products?
calebtv
This will hopefully be our last pivot :) BuildFlow never took off and we're still supporting the companies who use the LaunchFlow Python SDK.
null
cloudking
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.
TankeJosh
We’d like to add more background maintenance / optimization features after we get the 0→1 use case solid. The agent can do some basic analysis using its workflow tool + cloud CLIs, but it's definitely not designed for anything beyond diagnosing deployment errors.
Are you wanting something that runs during CI/CD? Or something that is constantly scanning your cloud looking for issues and potential improvements?
gitroom
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?
TankeJosh
Ideally both. The agent is really good at keeping environment and module configurations separate, which IMO gets rid of a lot of the common headaches.
What sort of breakages have you experienced with Terraform?
bberenberg
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".
TankeJosh
Sorry about that, there's a race condition in the client that occasionally happens when claiming your guest chats. Reloading the page should fix it.
bberenberg
No, this is persistent. The URL works fine in an incognito window, but it never bound to the main account.
TankeJosh
Do you mind sending me an email with your chat ID so I can dig into it? josh@launchflow.com
fabiofzero
Do you have any plans to expand to non-US based clouds? This is an urgent concern these days.
calebtv
We do want to support clouds beyond AWS, GCP, and Azure. That's one of the reasons we choose Terraform since it can be extendable to any cloud, and also why we plan on focusing on Kubernetes next.
65
It would be nice if this supported the AWS CDK.
TankeJosh
Its on the roadmap! The current plan is to add CDK docs / static checks after we finish adding Kubernetes support.
GhostCOM97
[dead]
curtisszmania
Love seeing tools that prioritize infrastructure reliability. Well done!
kajogo
[dead]
Hey HN, we’re Caleb, Michael, and Josh, the founders of infra.new (https://infra.new/), a DevOps Copilot that can configure and deploy apps on AWS, GCP, and Azure using Terraform and GitHub Actions.
You start by describing your infrastructure needs in detail and optionally attach any source code. The agent will clarify your requirements and either execute the task immediately or generate a plan with step-by-step instructions for you to approve. Once you’re happy with the changes, export everything to GitHub or let the agent provision it in your cloud account. Here’s a quick demo of deploying a new app to GCP / AWS: https://www.loom.com/share/4627b3cd96cc439e9981a38363b7f6f7
Why build a new coding agent when there are good ones already out there? We believe there’s room for a new agent that is specifically built for DevOps tasks since the risks are much higher – it's easy to rollback AI-related errors in a web app, but fixing a misconfigured database is not nearly as easy. By focusing specifically on cloud infra, we can provide all the visibility and checks you need to feel confident in your configuration changes.
At our previous jobs, we built an internal data / ML platform at Google Life Sciences that involved migrating off of internal Google infrastructure to the public cloud (GCP). We quickly learned how complicated it can be to configure cloud infrastructure well, even for seemingly simple tasks. Configuring an app with CI/CD requires knowledge of multiple infra tools, cloud services, and best practices. Mistakes can be costly and diagnosing issues can send you down a rabbit hole of cloud docs.
Our goal is to help engineers feel confident when making changes in their cloud. We designed the workflow to start with a prompt, a template, or a GitHub repository. After clarifying your requirements, the agent will start generating IaC, CI/CD, and other configurations using the latest docs, public Terraform Registries, and a set of best practices we dynamically load into the context window.
All changes are run through static analysis to detect hallucinations, estimate cost changes, and visualize your infrastructure components as you go. Once you’re happy with the changes, you can export everything to GitHub for review. You also have the option to deploy directly to your cloud from the workspace and let the agent diagnose any deployment issues. The deployment flow is "pseudo-deterministic" in that it follows a checklist of human-guided instructions that help it stay in bounds, but we still recommend only using this feature for dev environments and using GitOps for any changes to production.
The current plan is to continue adding support for more tools (Kubernetes and GitLab are next) and we may add a CLI that lets you bring the agent into your local workspace.
We’d love to hear your feedback and ideas!