Boogy: Production Infrastructure for Vibe Coders | Hacker News Reader

Boogy: Production Infrastructure for Vibe Coders

boogy.ai

2 pointsnotgelotto4 comments

We’re experienced engineers who’ve worked on large-scale distributed systems. We’ve been using Claude heavily to help with architecture decisions, code design, testing strategies, and rapid iteration on complex infrastructure.

The result is Boogy, prompt it (or write Rust) to generate full backends with an embedded high-perf DB (faster than SQLite on mixed workloads), vector search, auth, and durable jobs. One curl to deploy. Services call each other in-process for microsecond latency.

We’re planning to open it up soon and make it completely free so people can properly battle test it.

Would love to learn about what issues current vibe coders might be running into in production?

Getting an app running is rarely the hard part. Keeping it healthy a few months later usually is. How much thought has gone into things like incident response, monitoring, and operational tooling?

Hey man, thanks for the question. Regarding the problem of whether an app will still be healthy in three months: it's a matter of ongoing verification. I'm targeting early next week for launching a public testnet, where you can try deploying random shit to test it and/or try to break things. It would be welcomed and appreciated, actually :)

Here are some things I can say that we have thought about and built from the start:

- Per-tenant observability via Prometheus through a metrics API, with counters at hopefully all meaningful decision points -- ingress decisions, auth delegations, internal events, rates, etc.

- The audit/telemetry pipeline with methods that help ensure consistent performance at scale and graceful degradation under extreme and increasing load.

- Requests are assigned ID's that propagate end-to-end across hops in the mesh (e.g. internal peer service calls), so you can trace requests across them.

- ACID DB transactions ACROSS all internal service calls, spanning the entire service-to-service call graph.

- Incident response and recovery are first class considerations, but I don't want to go on and on. There are documented runbooks, rollbacks, transactional migrations for applying updates to code+data, etc etc.

---

Hope that helps.

Those are the current things we are wrapping up before the MVP release. We don't want to just make it easy to deploy, scale, & secure, we want to give you full insight into how your service is doing.

Reply on news.ycombinator.com