Deployments

Versions are immutable. Deploying promotes one, and rolling back promotes an older one — instantly, without rebuilding.

A function is durable and user-facing. A version is one immutable build of it. Every change produces a new version rather than mutating an existing one, which is what makes rollback instant and the deploy list an audit trail.

Ways to deploy

	What it does
Deploy from the console	Snapshots the current workspace and builds it.
Upload an archive	Deploys a zip you supply instead of the workspace.
Git push	A push to the connected branch builds and promotes automatically.
Deploy from git	Builds the connected repository on demand, optionally at a ref you name for this deploy only.
Redeploy	Produces a new version from an existing version's snapshot.
SDK or CLI	Any of the above from a script or a CI job, waiting for the build and failing the job if it fails.

Deploys promote by default — you deployed because you wanted it live. You can ask for a build without promotion and promote it separately.

Version states

State	Meaning
`PENDING`	Source is stored, the build has not started.
`BUILDING`	The image build is running.
`READY`	Built and promotable.
`FAILED`	The build failed; the reason is on the version and in its log.
`SUPERSEDED`	Was live, replaced by a later promotion.

A static version is READY the moment it exists — there is nothing to build.

A container deploy answers before its build finishes. The version comes back BUILDING and the build runs in the background, because a cold dependency install takes minutes and an HTTP request should not. It promotes itself when it succeeds. Builds are bounded at 30 minutes.

Promotion and rollback

Promoting a version points the function's traffic at it. A rollback is the same operation applied to an older version — nothing is rebuilt, so it is a pointer flip rather than a deploy.

The version list is the history: pick any READY version and promote it.

Redeploying

Redeploy answers two problems that promotion cannot:

Retrying a failed build. Without it, the only recourse is re-uploading identical source or pushing an empty commit.
Applying settings changes. Environment variables and secrets are read when a version's App is created, so a settings save on its own changes nothing that is running. Redeploy is the honest "apply now".

It always produces a new version from the source version's snapshot and never touches the version you asked about. You can ask for a rebuild, or reuse the already-built image where one exists.

Build logs

Build output is captured for every version and readable from the deploy's Logs tab, including after the build finishes — a failed build's log is the whole error message, and you should not have to have been watching.

A version that never builds (a static one) has an empty log rather than an error.

Application logs — your process's own stdout and stderr at runtime — are not available yet. The console shows the tab as awaiting server support rather than pretending. Build output is captured; runtime output is not.

What a deploy actually does

source ──► workspace import ──► snapshot ──► version ──► promote

The source tree is planned against the function's kind, producing either a build recipe or a static root.
The tree is imported into the function's workspace. The store is content-addressed and the workspace is reused across deploys, so unchanged files cost nothing the second time.
The workspace is frozen into an immutable snapshot. That snapshot is what a static version serves, and what a container build copies from.
For container functions, an image is built and published as a new version of the function's App.
Promotion points traffic at it.

A function's hostname belongs to a single App that is created once and reused — a new App per deploy would change your URL on every push.

Failure modes worth recognising

Symptom	Cause
Deploy times out on activation	The app is not listening on `$PORT`.
Build fails on a missing bundler	Node build script needs a dev dependency that was pruned — check your `build` script and lockfile.
Go build fails asking which command	Several directories under `cmd/`; set an explicit main package.
Static deploy fails finding content	No `index.html` at the root or in a conventional output directory.
URL 404s but the function exists	Nothing has been promoted yet.
URL returns 502	The active version is missing or the upstream is unreachable — this is deliberately not hidden behind a 404.