In its current form, infra.new would probably be most helpful when setting up new projects or migrating any old apps to this single monorepo setup, but it also sounds like Terraform isn't a huge pain point for your team.
I am interested to learn if we can help with these 2am pages though. Are those set up by you? Or the developers? Would an agent that helps improve observability / alerts configuration be interesting to you?
Maybe we should add a special agent mode to help with planning internal politics strategy ;)
I am curious what the handoff looks like between you and the devs you work with. Do they self-serve using the modules you publish? Or is there some sort of dev portal that abstracts away Terraform?
Yeah I don’t love the token-based pricing either, not sure if we'll keep it long term.
In practice you won't hit these limits, and if you do then you're probably a power user and we'll happily give you free quota in exchange for feedback :)
Appreciate the detailed feedback and definitely agree that wrapping these cloud services is a bad idea. Our last product did this and it went exactly how you described.
Our goal isn’t really to make deploying “easy” per se, we mainly want to help infra / DevOps teams make better configuration changes faster by blending AI code gen with specialized RAG + static analysis + human review. The cool thing about using LLMs for this use case is that we don’t need to do the 1:1 mapping you described, we can instead just teach the agent to use the underlying systems directly.
We like to think of ourselves as the anti-PaaS since we help engineering teams manage their own platform. Most of these teams already use Terraform and can continue to manage their infra however they like, they'll just do it faster and probably catch some issues that slipped through the cracks before.
Our launch post did a bad job mentioning this focus on infra teams, so I apologize if that caused any confusion! Maybe "the Cursor for infra teams" would be a better way to describe infra.new
There are definitely a lot of dragons, but there are also a lot of teams that use these tools and need help slaying those dragons :)
We chose to focus on IaC because we think general coding agents are going to take a long time to solve all the edge cases well.
I do think a similar tool built on something simpler would be really interesting. I’ve been tempted to try this with our previous product: https://docs.launchflow.com/
100% agree with everything you’re saying here. This tool is designed to make the infra / DevOps person more effective by spending less time on tedious tasks and instead focus on the high level architecture and cost of their infrastructure. The deployment feature is mainly for testing any configurations in dev / staging environments before integrating with GitOps.
The workflow we imagine is an infra team either managing everything on their own, or providing private Terraform modules that the rest of their developers can ask the agent to configure for them. For teams that go this developer self-service route, you can also set custom validation rules and default configurations that are shared across your team.
Looking back on our launch post we definitely did not highlight who this product was built for well enough. I’d love to hear if there’s any aspects of the tool that you think would be helpful for your work!
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?
I have not used Coolify before, but after looking at their docs I would say LaunchFlow is somewhere between Coolify and Terraform / Pulumi.
Similar to Terraform / Pulumi: you can define nearly any AWS / GCP resource with a line of Python code, then deploy it across all of your environments with the CLI.
Similar to Coolify: all of your environment-level configuration (networking, permissions, etc) is handled for you, but you can always customize the underlying Terraform modules with Python (or bring your own custom Terraform).
The environment abstraction makes it really easy to switch between cloud services. Most of the teams using LaunchFlow will use serverless deployments for dev environments, then switch to VMs / Kuberenetes in prod for better performance / pricing.
We spent the last 6 months refactoring our DevOps platform into an open source deployment tool for AWS / GCP.
If you’re not familiar with LaunchFlow, it's a Python SDK that lets you launch websites, APIs, and workers to AWS / GCP with minimal configuration.
Networking, permissions, and other environment configurations are automatically handled for you – It only takes 1 line of code to deploy static sites, serverless APIs, managed Postgres, Kubernetes clusters, and more.
Hey HN! We just relaunched LaunchFlow, an infrastructure-from-code tool that automatically deploys infrastructure to your own GCP / AWS account as you use it in your Python code.
Our tool is currently focused on making it easy to build Python APIs connected to cloud resources (ex: a FastAPI app connected to RDS Postgres on AWS). We plan on adding Jobs and Notebook deployments in the next few months.
I would love to hear your feedback on how we can improve your developer experience when building Python apps on the cloud.
If you’d be willing to try it out on a call with me, I’ll upgrade your account for free!
AWS support is in the queue, but we only have GCP services at the moment. What services on AWS do you need access to? We can move them to the front of the queue to help out.
Feel free to reach out even if this doesn’t work with your timeline. I might be able to help you come up with another solution, and I’m always interested to hear new use cases!
In its current form, infra.new would probably be most helpful when setting up new projects or migrating any old apps to this single monorepo setup, but it also sounds like Terraform isn't a huge pain point for your team.
I am interested to learn if we can help with these 2am pages though. Are those set up by you? Or the developers? Would an agent that helps improve observability / alerts configuration be interesting to you?