Skip to main content
Publishing puts your app on the internet at a public https:// address that starts with a name you choose. The agent asks for the name, then Alpha builds a fresh copy from your source and runs it outside the session’s machine, so it stays up while the machine sleeps. To change or roll back an app that is already live, see Manage a published app. To show work in progress instead, share the session.
Only the session’s owner sees Publish. If you don’t see it beside Share in your own session, publishing isn’t turned on for your Alpha. Ask whoever runs it.

​
How does publishing work?

Alpha copies one directory out of the session’s machine, works out how to build it, builds an image on Google Cloud Build and runs it on Google Cloud Run. Each publish is a new version. Traffic moves to it only once it serves, so a failed build never takes down what is already live. A Dockerfile in the directory wins and is built as it is; it must listen on $PORT. Otherwise Alpha detects the stack from the project’s manifest and picks the install, build and start commands. If the app needs a system package the builder doesn’t add by itself, such as ffmpeg, the agent names it in a railpack.json beside the app, as "deploy": {"aptPackages": ["ffmpeg"]} with Debian package names, or writes a Dockerfile instead.
The production database starts empty. Rows in the session’s database don’t move across. The agent migrates from the app’s start command, or you push the session’s tables from the Publish tab. See Production database and sign-in.

​
Before you publish

The agent checks the project before a first publish and fixes what it finds. An app that already follows these rules goes live unchanged.

​
Publish your app

Publishing is done by the agent, in the session, so you can see and answer everything it does.
1

Click Publish

Click Publish beside Share. While the agent is working, the pill is held and its tooltip reads “The agent is busy — ask once it is done”, because a message then would steer the turn. The Publish to production box shows what ships: Serves is the process and port serving a page in the Preview, or “detected from the code”. Database reads “its own, in production” or “none”, Sign-in reads “on” or “off”, and Access is always “Public · anyone with the URL”.
The Publish to production popover open below the Publish pill at the top right of the workspace, which follows the server.js tab, the + button and the GitHub and Share icons. A grey line under the title reads Google Cloud Run · us-east1. Four rows follow: Serves, node · 3000 in monospace; Database, its own, in production; Sign-in, off; Access, Public · anyone with the URL. A grey note reads The agent names it (the name is its address), builds it from source and publishes it; the Publish tab follows the rollout. Cancel and a white Publish button with a rocket icon sit at the bottom right. Behind the popover, code from server.js shows at the left and the files panel, with the public folder open, at the right.

Check what goes with the app before the agent starts.

2

Send the request

Click Publish in the box. Alpha sends “Deploy this.” to the agent, as if you had typed it. One click sends one message.
3

Answer the question card

The agent puts everything only you can decide into one question card: the name, with a suggestion first; the directory, when there is more than one; and which secrets production gets, when the app reads keys. The port and start command are the agent’s to settle.
4

Watch it go live

The Publish tab opens by itself and follows the build. The agent posts the address in the transcript when it is live. See Watch the rollout.
You can also start from the Publish tab: open it from + → Publish. Before anything is published, it reads “Ship this app to production” and lists the three stages, Name it, Build and Serve. Publish with the agent sends the same “Deploy this.” as the pill, and is held at the same times. You can also ask the agent: “deploy”, “publish”, “ship it”, “go live” and “put it online” all count. The agent never publishes unasked. Alpha will:
  1. Check what would be built, and fix anything that would stop it.
  2. Ask only what you haven’t said. Here the name and the secret are given, so with one directory nothing is left to ask.
  3. Publish the app and post its address.

​
Choose a name

The name is the first part of the address, so it can’t be changed later. Republishing keeps it. For a new address, publish under a new name and delete the old app. A taken name is refused with “the name harbor is taken — pick another”. When that happens, the agent picks another and tells you which.

​
Where does my app live?

Every app answers at https://<name>-<project number>.<region>.run.app. Access is public and https is included, so anyone with the address can open it once it is live. On some Alphas a short prefix sits in front of the name. Where your Alpha has its own domain, the app is also at https://<name>.<domain>, mapped after the first successful publish: You can’t attach a domain you own. Where there is a domain, it is the same for every app on your Alpha.

​
Watch the rollout

The build usually takes 2–6 minutes. The Publish tab tracks the version through Export, Plan, Build, Publish and Live, each marked Done, In progress, Failed or Waiting. The pill beside Share reads Publishing… meanwhile. Open the Log fold to read the build as it runs; secret values show as [redacted]. The transcript gets a card when the publish starts and one when it ends, visible to anyone who can read the transcript. Publish tab in each card opens the tab. A session publishes one app at a time; meanwhile the buttons are held with “A rollout is in progress”. You can close the browser. The publish runs on Alpha’s side, and the machine stays awake until it ends.

​
Limits

An idle app scales to zero, so the first request after a quiet spell is a little slower. What happens at each limit is on Limits.
Values marked “(default)” are set by whoever runs your Alpha, and yours may differ.

​
Next steps

Manage a published app

Republish the latest changes, or put any earlier version back in seconds without a rebuild.

Production database and sign-in

Give the empty production database its tables, then browse its rows from the Database tab.

Monitor and troubleshoot production

Read the live app’s logs and request metrics, and hand an error line to the agent.

Build and publish a landing page

Go from one message to a public page with a working signup form, step by step.