Show HN: Bay – open-source Render for AI-generated Code 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. 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