Skip to main content

​
Install and sign in

bay login opens a browser once. For CI and headless agents, pass a token instead — bay login --token <t>, or set BAY_TOKEN in the environment, which overrides anything saved.
The command installs as both bay and supersonic. The second name is what it had before and every existing script, CI job and agent prompt still says it — that alias is permanent, not deprecated.

​
Look before you ship

These two commands are local. No cloud, no build, no model, about two seconds each.
1

Write a draft config

Reads the repository and writes a draft supersonic.json: the monorepo split, the install command from the lockfile, the build command and output directory, the start command bound to $PORT, and the runtime version the manifests ask for.Then it prints what it could not work out, because those answers are not in the files:
2

Check what would run

Resolves and validates that file exactly as a deploy would, then prints, per service, the command each phase runs:
Non-zero exit on any problem, which is what makes it usable in a loop.

​
Ship it

Without --wait the command returns as soon as the URL exists and leaves the build running behind it. With --wait it stays attached and streams the build:
Nothing in that app declared a database. It imports pg and reads DATABASE_URL; the dependency is the declaration, and everything from Provision postgres onward follows from it.

​
What you have now

A live app

At <name>.thebay.cloud, private by default. bay share <app> public opens it to anyone with the link.

A lock file

supersonic.lock.json — what this ship decided, written next to your config so you can read it and change it.

​
Ship again

Or connect the repository and let a push do it — see Shipping from GitHub.