{"slug": "show-hn-bay-open-source-render-for-ai-generated-code", "title": "Show HN: Bay – open-source Render for AI-generated Code", "summary": "Bay, an open-source platform from thebay.cloud, lets coding agents deploy AI-generated code to live URLs without manual configuration, provisioning databases and storage automatically. The tool, previously named Supersonic, supports frameworks like Next.js, Django, Rails, Go, and Phoenix, and is available via npm as @thebaycloud/cli.", "body_md": "**Bay — the cloud for the agentic era.**\n\nYou don't pick a database, a region, or an instance size. Your coding agent and Bay work that out, ship it to a real address, and keep it alive.\n\n[ thebay.cloud](https://thebay.cloud) ·\n\n[Docs](https://bay.mintlify.app)·\n\n[Templates](https://thebay.cloud/templates)·\n\n[Changelog](https://thebay.cloud/changelog)\n\nPaste that link into Claude Code, Cursor, Codex or Copilot and say \"set this up\".\nNo account, no dashboard step, no keys to find first — the agent reads the manual at\nthebay.cloud/llms.txt and drives the rest.\n\n```\nnpm install -g @thebaycloud/cli && bay ship\n```\n\nOne unedited take: a coding agent is asked to put the app online, installs the\nCLI, ships, and verifies the app is serving with Postgres wired in — ending on the\nlive URL with the owner's toolbar on it.\nWatch it directly if the player does not load. Recorded before the\nrename, so the recording says Supersonic and the address ends .supersonic.cv; the\nproduct is Bay and new apps get *.thebay.cloud.\n\nPoint Bay at a folder or a repository. It reads the code, works out how to build it, provisions the database and storage the code implies, injects the credentials, and serves the result on a real address with a certificate. Next, Django, Rails, Go, Phoenix, or anything that can be put in a container.\n\nThere is no configuration step you have to get through first. `examples/pgapp`\n\ncontains no Dockerfile, no infrastructure, and no mention of a database — just\n`require(\"pg\")`\n\nand a `DATABASE_URL`\n\nit expects somebody else to set. That\ndependency is the request; Bay reads it, provisions Postgres, isolates it, and\nfills the variable in.\n\n**The shape of it.** One control plane decides, and nothing pushes to a machine:\n\n```\n     you  ·  your coding agent\n              │  CLI · GitHub push · git URL\n              ▼\n       control plane            resolve the config, plan the build, provision\n              │\n     ┌────────┴────────┐\n     ▼                 ▼\n  the fleet         static apps\n  one sandbox       published to a bucket\n  per app, a\n  resident agent\n  pulling desired\n  state\n              │\n              ▼\n   load balancer ◄── wildcard DNS + SSL\n```\n\nEach node pulls its desired state, compares it to what is running, and makes the\ndifference go away. That single loop is the whole runtime — which is why a node\nthat falls behind catches up on its own rather than needing anybody to reach into\nit. Images are built on the fleet's own BuildKit, whose cache is local to the node\nand stays warm, and are deployed **by digest**, so \"the new version\" is a fact\nrather than a tag.\n\nIf Bay is useful to you, a star is the cheapest way to say so — and the thing that decides whether the next person finds it.\n\n```\nnpm install -g @thebaycloud/cli\ncd your-project\nbay ship --wait\n```\n\nA real bay ship --wait against examples/pgapp, which is\nstill up.\n\nThe first run opens a browser once so you can sign in; after that the token is on\ndisk and your agent inherits it. Without `--wait`\n\n, `ship`\n\nreturns as soon as the URL\nis live and the build continues behind it; with `--wait`\n\nit stays attached and\nstreams the build to completion, which is the mode to give an agent that needs to\nknow the deploy finished before it does anything else.\n\nTwo commands worth knowing before the first ship, because both are local — no cloud, no build, about two seconds each:\n\n```\nbay init     # writes a draft supersonic.json, and names what it could NOT determine\nbay check    # resolves and validates that file exactly as a deploy would\n```\n\n`bay init`\n\nprints its open questions rather than guessing at them — which service\nowns `/`\n\n, whether a migration runs before traffic, which env names are secrets.\nNone of those are answerable from files, and a guess would be indistinguishable\nfrom a decision.\n\nPostgres, MySQL, Mongo and Redis come up with your app, picked from what your code\nalready imports. Object storage sits behind a CDN. Workers and cron run beside the\nweb process, and a `release`\n\nphase runs before any traffic reaches it. You\nprovision none of it.\n\nNobody provisioned that database. It is one app's own Postgres, with the tables\nits code created, browsable from the app's page.\n\nBay watches the app after it is live. When something breaks in production, it reads the logs and the repository together and returns an instruction written for the thing that wrote the code:\n\n```\nbay errors <app>     # production errors, last 7 days\nbay diagnose <app>   # a fix prompt, ready to paste into your coding agent\n```\n\nA real failed deploy. Bay says what broke, shows what the pipeline decided on\nthe way there, and hands back the instruction — not a stack trace to interpret.\n\n`diagnose`\n\ndoes not print a stack trace and leave you to it. It prints the actual\nsentence — *migrations never ran, so the schema is empty; add a release step that\nruns them before the web process starts, then deploy again* — because a trace is\nthe symptom and the agent needs the cause.\n\nEverything the dashboard does, the CLI does, and every command takes `--json`\n\n:\n\n```\nbay apps                          # everything you have shipped\nbay status <app>                  # revision, url, env, database\nbay logs <app> --follow           # what production actually saw, live\nbay share <app> add ada@acme.com  # let one person in, or a whole domain\nbay domains <app> add acme.com    # a domain you own, and the record to create\nbay db <app> --sql \"select ...\"   # its tables, row counts, one read-only statement\nbay exec <app> -- <command>       # run something in the app's environment\nbay rollback <app>                # back to the version that worked\nbay env <app> set KEY=VALUE       # secrets, never in the code\n```\n\n`bay help --all`\n\nlists the rest. Anything that can run a command can run your\ninfrastructure — which is the point, because the thing running commands is usually\nnot a person any more.\n\n**MCP is next.** Your agent will call Bay as tools instead of shelling out —\ndeploy, read the logs, apply a fix, without leaving the editor it is already in.\nNot shipped yet, and labelled that way here for the same reason it is labelled that\nway on the site.\n\nThe address answers **before the app does**. Until the app is ready, the URL you\nwere handed serves the build itself, and every movement in it stands for one real\nline of that build.\n\nFrames from one real build at m1d9l.thebay.cloud. The log along the bottom is\nthat build's own output and the counter is its real stage. Only the owner sees this —\nsend the link to anybody else and they get a page with no build on it.\n\nBay runs software you did not write as happily as software you did, and\n**self-hosting a public repository is free for the first year.**\n\nThe [templates](https://thebay.cloud/templates) — Excalidraw, Open WebUI, Cal.com —\nare prompts rather than buttons. You copy one, your agent reads it, clones the\nsource and ships it. No form and no dashboard step, since the agent is already\nholding everything the deploy needs.\n\nEach template page says up front what gets provisioned, which secrets are generated for you, and the one or two only you can supply. A one-click deploy that then demands a Google OAuth client is worse than a page that warned you.\n\nNothing above needs it.\n\n**Everything below is how it is built.** Nothing above needs it.\n\n**This repository is open to read, not yet to run.** Bay is welded to one Google\nCloud project — Cloud Run, Cloud SQL, Cloud Build, Certificate Manager, Artifact\nRegistry, Secret Manager and Compute for the fleet — not as configuration you could\npoint elsewhere, but as the assumption underneath the code. There is no\n`docker compose up`\n\nand no local mode.\n\nYou can read every line and run the test suites. You cannot stand up your own copy\nwithout a GCP project, billing, and a day of work nobody has written down yet. That\nis said here rather than discovered after a clone. If self-hosting Bay itself\nmatters to you, [open an issue](https://github.com/thebaycloud/bay/issues) — it is\na question of demand, not of principle.\n\n| Path | What it is |\n|---|---|\n`apps/web` |\nThe control plane. API, dashboard, deploy pipeline, build orchestration, billing, GitHub integration. Next.js 14 · Postgres · NextAuth. Every decision the platform makes happens here — including `lib/buildplane.ts` , which drives BuildKit |\n`apps/landing` |\n`/llms.txt` , the manual coding agents read |\n\n`packages/cli`\n\n`bay`\n\n— the CLI on npm ([MIT](/thebaycloud/bay/blob/main/packages/cli/LICENSE))`packages/detector`\n\n`packages/prompts`\n\n`scripts/sync-prompt-rules.mjs`\n\n`services/fleet`\n\n`supersonicd`\n\n— the Go agent on each VM: reconcile loop, sandboxes, router. Plus the node image and `fleetctl.sh`\n\n`services/proxy`\n\n`services/static`\n\n`services/screenshots`\n\n`scripts/`\n\n`examples/`\n\n`adrs/`\n\n[CONTRIBUTING.md](/thebaycloud/bay/blob/main/CONTRIBUTING.md)`docs/`\n\n[,](/thebaycloud/bay/blob/main/docs/ARCHITECTURE.md)`ARCHITECTURE.md`\n\n[, and the](/thebaycloud/bay/blob/main/docs/VM-FLEET.md)`VM-FLEET.md`\n\n[ADRs](/thebaycloud/bay/blob/main/docs/adr)Two documents are worth reading before you change anything:\n\n— the vocabulary. There are two languages here, platform and product, and they do not mix. A word in the wrong one is a bug.`CONTEXT.md`\n\n— how agents work in this repo: the issue tracker, the triage labels, where domain docs live.`AGENTS.md`\n\n```\ngit clone https://github.com/thebaycloud/bay.git && cd bay\n```\n\nThe control plane talks to two Cloud SQL instances — its own tables on one,\nevery app's database on the other — so running `apps/web`\n\nagainst real data means\none `cloud-sql-proxy`\n\nper instance:\n\n```\ncloud-sql-proxy -g --port 5433 <project>:<region>:supersonic-platform-pg\ncloud-sql-proxy -g --port 5434 <project>:<region>:supersonic-shared-pg\ncd apps/web\nnpm install\nnpm run dev        # http://localhost:3000\nnpm test\nnpm run lint\nnpm run deadcode   # knip\n```\n\nMigrations in `apps/web/db/*.sql`\n\nare applied deliberately, never automatically:\n\n```\nnpm run db:migrate\n```\n\nCareful:never run the`apps/web`\n\nsuite under`git bisect run`\n\n— the fixtures write into the real`.git`\n\n.\n\n**No GCP account?** Most of the repo doesn't need one. The CLI, the fleet agent\nand the fixtures all build and test on their own:\n\n```\ncd packages/cli         && npm install && npm test\ncd services/fleet/agent && go build ./... && go test ./...\ncd apps/landing         && npm install && npm run dev\n```\n\nCI runs all of it on every pull request.\n\n**We take contributions as human-written text, not code** — see\n[CONTRIBUTING.md](/thebaycloud/bay/blob/main/CONTRIBUTING.md). Describe the change you would like informally\nin a `.txt`\n\nor `.md`\n\nfile in [ adrs/](/thebaycloud/bay/blob/main/adrs) and open a pull request with just\nthat file. If we are aligned, we handle the implementation.\n\nThat is not a filter on your writing. A change to the deploy pipeline, the edge, or the fleet agent lands on live tenant applications minutes after it merges, and reviewing a patch against that costs more than reading a paragraph does.\n\nBugs are [issues](https://github.com/thebaycloud/bay/issues). Vulnerabilities are\nprivate — [SECURITY.md](/thebaycloud/bay/blob/main/SECURITY.md), never a public issue. Before writing anything\nhere, read [ CONTEXT.md](/thebaycloud/bay/blob/main/CONTEXT.md) and match the vocabulary.\n\n[AGPL-3.0](/thebaycloud/bay/blob/main/LICENSE), except `packages/cli`\n\n, which is [MIT](/thebaycloud/bay/blob/main/packages/cli/LICENSE)\nso it can be installed anywhere without pulling its licence along.", "url": "https://wpnews.pro/news/show-hn-bay-open-source-render-for-ai-generated-code", "canonical_source": "https://github.com/thebaycloud/bay", "published_at": "2026-08-25 15:30:36+00:00", "updated_at": "2026-08-25 15:47:31.237310+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "ai-infrastructure"], "entities": ["Bay", "thebay.cloud", "Supersonic", "Claude Code", "Cursor", "Codex", "Copilot", "BuildKit"], "alternates": {"html": "https://wpnews.pro/news/show-hn-bay-open-source-render-for-ai-generated-code", "markdown": "https://wpnews.pro/news/show-hn-bay-open-source-render-for-ai-generated-code.md", "text": "https://wpnews.pro/news/show-hn-bay-open-source-render-for-ai-generated-code.txt", "jsonld": "https://wpnews.pro/news/show-hn-bay-open-source-render-for-ai-generated-code.jsonld"}}