TankeJosh

Thanks for sharing, this is really helpful info!

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?

Thank you for the kind words! Would love to hear your thoughts if you have a chance to try it.

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!

Do you mind sending me an email with your chat ID so I can dig into it? [email protected]

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?

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?

Its on the roadmap! The current plan is to add CDK docs / static checks after we finish adding Kubernetes support.

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.

Thank you for the feedback! Would love to hear your thoughts when you have a chance to try it.

I appreciate it! Feel free to email me at [email protected] if you hit any issues!

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.

Environments Docs: https://docs.launchflow.com/docs/concepts/environments

Hey HN,

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.

I would love to hear your thoughts!

Was hoping for more feedback, I'll try again in the future!

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!

We're thinking about attending this year's conference, so maybe we'll see you there :)

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!

You can think of BuildFlow as a lightweight alternative to Flink / Spark Streaming. These streaming frameworks are great when you want to react to events in realtime (i.e. you want to trigger some processing logic every time a file is uploaded to cloud storage). Dagster is more focused on scheduling jobs, and might be a good fit if you have some batch jobs you want to trigger occasionally.

BuildFlow can run a simple PubSub -> light processing -> BigQuery pipeline at about 5-7k messages / second on a 4core VM (tested on GCP’s n1-standard-4 machines). For your case, you might be able to get away with running on a single machine with 4-8 cores.

I’d be happy to connect outside of HN if you’d like me to dig into your use case more! You can reach me at [email protected]

edit: You can also reach out on our discord: https://discordapp.com/invite/wz7fjHyrCA

We chose not to reference them because we are mainly focused on streaming use cases, which don't fit well in the prefect & dagster models.

Notebook execution should already work! The flow.run(...) call returns the output collection with this use case in mind. We're currently working on a docker manager module which will let users easily dockerize / run their pipeline locally. The system (repl) debugger tool in our VSCode extension will manage all of the docker bits for the user.

Thanks for the catch! We just pushed a fix.