Just Dashboard Releases, retries, and rollback
Follow a deployment run, compare releases, retry a failure, or restore a retained release.
Every deployment run has its own page and durable sequence of steps. Open Deployments → your project → Deployments, then select a run. Its page shows the commit it built, who started it, its state and duration, the release path, how it ended, its build logs, and the details of every step. A run's URL remains a useful link after the page is closed.
Follow a run
The release path shows source acquisition, plan checks, build or image pull, release tasks, backup and certificate gates where configured, candidate startup, readiness, activation, and recording. A failed run names the step it stopped at, the engine's reason, and the last lines the step wrote, and links to the setting that can fix it when the cause is known. Show the line opens the build logs at the line that explains the failure. What the release does once it runs is on the project's Logs and Runtime pages, not on the run.
Logs shows what the managed public route served: requests, failing share, p95 latency, path and client insights, container output, and lifecycle events. Release activations are marked on its request chart. If a project has no managed route, request readings may be unavailable; use Output and Events instead.
Choose the right action
| Action | What it does |
|---|---|
| Deploy changes | Builds the current desired project configuration and source revision. Saved changes that are pending become live only when their run succeeds. Before the first release it reads Deploy. |
| Redeploy / Redeploy live release | Runs the live release's selected immutable identity through the release checks and cutover path again. |
| Rebuild without cache | Starts a new build from the current desired source without reusing build cache. |
| Retry | Replays a failed or cancelled run using that run's frozen plan and variable revisions. If settings changed since then, it reads Retry with the settings it used, and the run offers Deploy with current settings. |
| Restart | Stops and starts the current live runtime, then runs its readiness checks. It creates no new release. |
| Stop / Start | Stops the live runtime in place or starts that same release again. While stopped, automatic branch deployments do not enqueue. Stop and Restart ask before they interrupt visitors. |
| Deploy a specific version… | Builds a selected branch, tag, or commit of a Git project without moving the branch followed by automatic deployment. |
| Roll back | Activates an available retained release through the same safety checks and routing path. |
Compare and roll back
On the Deployments page or a run's page, open a successful run's menu and choose Compare with live or What changed in this release. The comparison covers runtime and source, variables, dependencies, checks, and domains. A retained release can be pinned with Pin release so artifact cleanup keeps it beyond the ordinary retention window. The normal plan keeps the live release and five previous successful rollback releases, along with needed candidates and pins; an older unpinned artifact may no longer be available.
Choose Roll back to this release and read the dialog's route and replacement summary before confirming. Rollback changes the application artifact and recorded release configuration. It does not rewind persistent volumes, a linked database, or changes a migration already made. If the previous code cannot read the newer data shape, restore the relevant backup or use an application-specific migration plan. See storage, databases, and backups.
For eligible stateless HTTP services, the candidate can pass health checks before the route moves. Compose, fixed-port, game, and exclusive-storage plans use stop-first replacement and may interrupt traffic. A failed candidate cannot simply become the live release. The run records recovery evidence if a cutover needs to restore the predecessor.
Archive and delete
Archive deployment disables its automation but keeps its history, runtime, routes, and data. You can restore the project from the archived list, then deliberately re-enable any triggers or schedules you still want. Remove managed resources is a separate previewed operation in Settings → Danger zone.
Delete permanently is available only after archiving and asks you to type the project's name. It removes the saved configuration, variables, release history, and deployment logs. It does not remove containers, images, routes, database networks, volumes, checkouts, or files on the server. Remove managed resources before permanent deletion when you want those resources cleaned up.