didierbreedt

I’ve been dealing with a similar problem. Something like this sounds awesome.

Somehow the “distribution” problem needs to be solved. Like, if you have a genuinely good product, it could fail because you suck at marketing and the world would never know.

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:

  news-api-db:

    type: postgresql

    class: postgresql.c0.tiny

    config:

      databaseName: newsapi

      databaseUsername: newsapi

    env:

      url: DATABASE_URL

-----

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.

Hey!

Yeah exactly that. Currently an admin Kubeconfig is exposed but proper user management will follow. From there, you are really in full control. We aim to make the repetitive stuff easy and leave the custom stuff up to you. You will have full control of the cluster.

As for custom configs, yeah we expose flags and config params to populate things that must be changed, like max_session in a db or innodb_buffer_pool, etc. But you are able to set any custom flags you want via console.

I’m waiting for a llm focused language. We’re already seeing AI is better with strongly typed languages. If we think about how an agent can ensure correctness as instructed by a human, as the priority, things could get interesting. Question is, will humans actually be able to make sense of it? Do we need to?

I have found Grafana to be a decent product, but Prom needs a better horizontally scalable solution. We use Vector and Clickhouse for logging and works really well.