Skip to main content
Bay takes an app you have already written and runs it. You do not describe your infrastructure to it, and you do not write a Dockerfile: it reads the repository, works out how to build it, provisions what the code implies it needs, and serves it on a real address.

What it does on its own

The list below is not configuration you write. It is what Bay infers from the code and creates for you.

A database

Postgres, MySQL, Mongo or Redis, chosen from the driver or ORM you import. Isolated per app, with the credentials injected under every name your stack is likely to read.

Secrets

The only thing Bay ever asks you for. Stored in Secret Manager, delivered to the build and the runtime, never written to a file.

An address

<name>.thebay.cloud the moment you ship, and a domain of your own whenever you point one at it.

Jobs

A release step that runs once before traffic, plus any number of workers and crons declared alongside the web process.

The two things worth knowing first

A ship returns a URL in about a tenth of a second — long before anything has been built. Until the app is ready that URL serves the Room: the build itself, drawn, at the app’s own address. Every movement in it stands for one real line of the build.Only the owner sees the Room. Send the link to someone else while it is building and they get a page with no build on it — not the same page with parts switched off.
bay init writes a draft config and then prints what it could not determine — which service owns /, whether a migration must run before traffic, which environment names are secrets. None of those are answerable from files, and a guess would be indistinguishable from a decision.That is the shape of the whole product: it infers what code can prove, and asks about the rest.

Where to go next

Quickstart

From an empty terminal to a live URL.

Concepts

The words this product uses, and what each one means.

CLI reference

Every command, and the --json behind each.