What is the strategy to deal with pay-as-you-go services used in vibe coded apps? I am always worried about the risk of some bad loop consuming thousands of dollars in a day.
Hmm, hard to control something like this from the MCP. My approach would be limit funds per hour/day and add to ctx via memory or prompt to not retry fixing something more than n times.
Hey HN. I've been doing backend and DevOps work for 20 years. About a year ago I started building RunOS after watching a company I worked at spend a small fortune on AWS for infrastructure that didn't need to be there. We moved some of it to Hetzner and the savings were ridiculous. That experience stuck with me.
RunOS is a platform that lets you run your own cloud on any hardware. Today I'm sharing a new feature called Vibe Deploy that connects AI coding tools (currently Claude Code) to your infrastructure through an MCP server.
The flow looks like this: you describe your app in conversation, the AI writes the code, constructs a minimal runos.yaml file, and RunOS handles everything else. Server provisioning, Kubernetes setup, database creation, building, deploying. The runos.yaml for a typical app with a Postgres database is about 10 lines:
The MCP server uses lazy docs loading rather than stuffing the full RunOS documentation into the LLM context window upfront. The base instructions just tell the AI how to pull additional information on demand via REST API. It fetches only the docs it needs based on the conversation. Keeps context lean and responses accurate.
An accidental nice find was the debugging loop. When a deploy fails, the AI automatically checks build logs, reads app logs, finds the error, fixes the code and redeploys. I've watched it catch a TypeScript type error in a database pool config, fix it, redeploy, then catch a bad migration, fix that too, and get the app running. All without intervention.
After deploy, the MCP connection stays useful. You can query your database in natural language, check object storage, read logs. No separate database client or CLI needed.
The cost angle matters too. A 10 node cluster on AWS runs roughly $2,500/month. Same thing on DigitalOcean is under $1,000. On Hetzner through RunOS it's under $250.
Where we're at honestly: it's late beta. Four services are available for AI provisioning right now (PostgreSQL, MySQL, Valkey, MinIO), more coming. There are probably bugs. We're heading to production in the next couple of months.
The scope ranges from single node setups for prototypes to multi-cluster, multi-node environments. The goal is to be a serious enterprise offering, not just a toy for side projects.
One use case I'm particularly interested in: teams where developers want to spin up prototypes quickly without bothering DevOps every time. Provision a server in your own network, deploy through AI, iterate fast. No tickets, no waiting.
2 min demo at runos.com. Happy to answer any questions about the architecture or approach.
What is the strategy to deal with pay-as-you-go services used in vibe coded apps? I am always worried about the risk of some bad loop consuming thousands of dollars in a day.
Hmm, hard to control something like this from the MCP. My approach would be limit funds per hour/day and add to ctx via memory or prompt to not retry fixing something more than n times.
Hey HN. I've been doing backend and DevOps work for 20 years. About a year ago I started building RunOS after watching a company I worked at spend a small fortune on AWS for infrastructure that didn't need to be there. We moved some of it to Hetzner and the savings were ridiculous. That experience stuck with me.
RunOS is a platform that lets you run your own cloud on any hardware. Today I'm sharing a new feature called Vibe Deploy that connects AI coding tools (currently Claude Code) to your infrastructure through an MCP server.
The flow looks like this: you describe your app in conversation, the AI writes the code, constructs a minimal runos.yaml file, and RunOS handles everything else. Server provisioning, Kubernetes setup, database creation, building, deploying. The runos.yaml for a typical app with a Postgres database is about 10 lines:
-----
app: news-api
port: 3000
requires:
-----The MCP server uses lazy docs loading rather than stuffing the full RunOS documentation into the LLM context window upfront. The base instructions just tell the AI how to pull additional information on demand via REST API. It fetches only the docs it needs based on the conversation. Keeps context lean and responses accurate.
An accidental nice find was the debugging loop. When a deploy fails, the AI automatically checks build logs, reads app logs, finds the error, fixes the code and redeploys. I've watched it catch a TypeScript type error in a database pool config, fix it, redeploy, then catch a bad migration, fix that too, and get the app running. All without intervention. After deploy, the MCP connection stays useful. You can query your database in natural language, check object storage, read logs. No separate database client or CLI needed.
The cost angle matters too. A 10 node cluster on AWS runs roughly $2,500/month. Same thing on DigitalOcean is under $1,000. On Hetzner through RunOS it's under $250.
Where we're at honestly: it's late beta. Four services are available for AI provisioning right now (PostgreSQL, MySQL, Valkey, MinIO), more coming. There are probably bugs. We're heading to production in the next couple of months. The scope ranges from single node setups for prototypes to multi-cluster, multi-node environments. The goal is to be a serious enterprise offering, not just a toy for side projects.
One use case I'm particularly interested in: teams where developers want to spin up prototypes quickly without bothering DevOps every time. Provision a server in your own network, deploy through AI, iterate fast. No tickets, no waiting.
2 min demo at runos.com. Happy to answer any questions about the architecture or approach.