# Show HN: Bay – open-source Render for AI-generated Code > Source: > Published: 2026-08-25 15:30:36+00:00 **Bay — the cloud for the agentic era.** You 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. [ thebay.cloud](https://thebay.cloud) · [Docs](https://bay.mintlify.app)· [Templates](https://thebay.cloud/templates)· [Changelog](https://thebay.cloud/changelog) Paste that link into Claude Code, Cursor, Codex or Copilot and say "set this up". No account, no dashboard step, no keys to find first — the agent reads the manual at thebay.cloud/llms.txt and drives the rest. ``` npm install -g @thebaycloud/cli && bay ship ``` One unedited take: a coding agent is asked to put the app online, installs the CLI, ships, and verifies the app is serving with Postgres wired in — ending on the live URL with the owner's toolbar on it. Watch it directly if the player does not load. Recorded before the rename, so the recording says Supersonic and the address ends .supersonic.cv; the product is Bay and new apps get *.thebay.cloud. Point 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. There is no configuration step you have to get through first. `examples/pgapp` contains no Dockerfile, no infrastructure, and no mention of a database — just `require("pg")` and a `DATABASE_URL` it expects somebody else to set. That dependency is the request; Bay reads it, provisions Postgres, isolates it, and fills the variable in. **The shape of it.** One control plane decides, and nothing pushes to a machine: ``` you · your coding agent │ CLI · GitHub push · git URL ▼ control plane resolve the config, plan the build, provision │ ┌────────┴────────┐ ▼ ▼ the fleet static apps one sandbox published to a bucket per app, a resident agent pulling desired state │ ▼ load balancer ◄── wildcard DNS + SSL ``` Each node pulls its desired state, compares it to what is running, and makes the difference go away. That single loop is the whole runtime — which is why a node that falls behind catches up on its own rather than needing anybody to reach into it. Images are built on the fleet's own BuildKit, whose cache is local to the node and stays warm, and are deployed **by digest**, so "the new version" is a fact rather than a tag. If 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. ``` npm install -g @thebaycloud/cli cd your-project bay ship --wait ``` A real bay ship --wait against examples/pgapp, which is still up. The first run opens a browser once so you can sign in; after that the token is on disk and your agent inherits it. Without `--wait` , `ship` returns as soon as the URL is live and the build continues behind it; with `--wait` it stays attached and streams the build to completion, which is the mode to give an agent that needs to know the deploy finished before it does anything else. Two commands worth knowing before the first ship, because both are local — no cloud, no build, about two seconds each: ``` bay init # writes a draft supersonic.json, and names what it could NOT determine bay check # resolves and validates that file exactly as a deploy would ``` `bay init` prints its open questions rather than guessing at them — which service owns `/` , whether a migration runs before traffic, which env names are secrets. None of those are answerable from files, and a guess would be indistinguishable from a decision. Postgres, MySQL, Mongo and Redis come up with your app, picked from what your code already imports. Object storage sits behind a CDN. Workers and cron run beside the web process, and a `release` phase runs before any traffic reaches it. You provision none of it. Nobody provisioned that database. It is one app's own Postgres, with the tables its code created, browsable from the app's page. Bay 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: ``` bay errors # production errors, last 7 days bay diagnose # a fix prompt, ready to paste into your coding agent ``` A real failed deploy. Bay says what broke, shows what the pipeline decided on the way there, and hands back the instruction — not a stack trace to interpret. `diagnose` does not print a stack trace and leave you to it. It prints the actual sentence — *migrations never ran, so the schema is empty; add a release step that runs them before the web process starts, then deploy again* — because a trace is the symptom and the agent needs the cause. Everything the dashboard does, the CLI does, and every command takes `--json` : ``` bay apps # everything you have shipped bay status # revision, url, env, database bay logs --follow # what production actually saw, live bay share add ada@acme.com # let one person in, or a whole domain bay domains add acme.com # a domain you own, and the record to create bay db --sql "select ..." # its tables, row counts, one read-only statement bay exec -- # run something in the app's environment bay rollback # back to the version that worked bay env set KEY=VALUE # secrets, never in the code ``` `bay help --all` lists the rest. Anything that can run a command can run your infrastructure — which is the point, because the thing running commands is usually not a person any more. **MCP is next.** Your agent will call Bay as tools instead of shelling out — deploy, read the logs, apply a fix, without leaving the editor it is already in. Not shipped yet, and labelled that way here for the same reason it is labelled that way on the site. The address answers **before the app does**. Until the app is ready, the URL you were handed serves the build itself, and every movement in it stands for one real line of that build. Frames from one real build at m1d9l.thebay.cloud. The log along the bottom is that build's own output and the counter is its real stage. Only the owner sees this — send the link to anybody else and they get a page with no build on it. Bay runs software you did not write as happily as software you did, and **self-hosting a public repository is free for the first year.** The [templates](https://thebay.cloud/templates) — Excalidraw, Open WebUI, Cal.com — are prompts rather than buttons. You copy one, your agent reads it, clones the source and ships it. No form and no dashboard step, since the agent is already holding everything the deploy needs. Each 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. Nothing above needs it. **Everything below is how it is built.** Nothing above needs it. **This repository is open to read, not yet to run.** Bay is welded to one Google Cloud project — Cloud Run, Cloud SQL, Cloud Build, Certificate Manager, Artifact Registry, Secret Manager and Compute for the fleet — not as configuration you could point elsewhere, but as the assumption underneath the code. There is no `docker compose up` and no local mode. You can read every line and run the test suites. You cannot stand up your own copy without a GCP project, billing, and a day of work nobody has written down yet. That is said here rather than discovered after a clone. If self-hosting Bay itself matters to you, [open an issue](https://github.com/thebaycloud/bay/issues) — it is a question of demand, not of principle. | Path | What it is | |---|---| `apps/web` | The 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 | `apps/landing` | `/llms.txt` , the manual coding agents read | `packages/cli` `bay` — the CLI on npm ([MIT](/thebaycloud/bay/blob/main/packages/cli/LICENSE))`packages/detector` `packages/prompts` `scripts/sync-prompt-rules.mjs` `services/fleet` `supersonicd` — the Go agent on each VM: reconcile loop, sandboxes, router. Plus the node image and `fleetctl.sh` `services/proxy` `services/static` `services/screenshots` `scripts/` `examples/` `adrs/` [CONTRIBUTING.md](/thebaycloud/bay/blob/main/CONTRIBUTING.md)`docs/` [,](/thebaycloud/bay/blob/main/docs/ARCHITECTURE.md)`ARCHITECTURE.md` [, and the](/thebaycloud/bay/blob/main/docs/VM-FLEET.md)`VM-FLEET.md` [ADRs](/thebaycloud/bay/blob/main/docs/adr)Two documents are worth reading before you change anything: — 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` — how agents work in this repo: the issue tracker, the triage labels, where domain docs live.`AGENTS.md` ``` git clone https://github.com/thebaycloud/bay.git && cd bay ``` The control plane talks to two Cloud SQL instances — its own tables on one, every app's database on the other — so running `apps/web` against real data means one `cloud-sql-proxy` per instance: ``` cloud-sql-proxy -g --port 5433 ::supersonic-platform-pg cloud-sql-proxy -g --port 5434 ::supersonic-shared-pg cd apps/web npm install npm run dev # http://localhost:3000 npm test npm run lint npm run deadcode # knip ``` Migrations in `apps/web/db/*.sql` are applied deliberately, never automatically: ``` npm run db:migrate ``` Careful:never run the`apps/web` suite under`git bisect run` — the fixtures write into the real`.git` . **No GCP account?** Most of the repo doesn't need one. The CLI, the fleet agent and the fixtures all build and test on their own: ``` cd packages/cli && npm install && npm test cd services/fleet/agent && go build ./... && go test ./... cd apps/landing && npm install && npm run dev ``` CI runs all of it on every pull request. **We take contributions as human-written text, not code** — see [CONTRIBUTING.md](/thebaycloud/bay/blob/main/CONTRIBUTING.md). Describe the change you would like informally in a `.txt` or `.md` file in [ adrs/](/thebaycloud/bay/blob/main/adrs) and open a pull request with just that file. If we are aligned, we handle the implementation. That 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. Bugs are [issues](https://github.com/thebaycloud/bay/issues). Vulnerabilities are private — [SECURITY.md](/thebaycloud/bay/blob/main/SECURITY.md), never a public issue. Before writing anything here, read [ CONTEXT.md](/thebaycloud/bay/blob/main/CONTEXT.md) and match the vocabulary. [AGPL-3.0](/thebaycloud/bay/blob/main/LICENSE), except `packages/cli` , which is [MIT](/thebaycloud/bay/blob/main/packages/cli/LICENSE) so it can be installed anywhere without pulling its licence along.