UI Walkthrough

pw-launcher opens at http://<your-server>:8080 and presents three tabs: Builds, Timeline, and Settings. This page walks each tab and explains what you are looking at.

Builds tab

The Builds tab is the default view and where most operator work happens.

The build list

Each row in the list represents a build — a specific version of PodWarden produced by a single CI run. Builds are identified by a sha-{commit} tag that never changes. Other tags on the same row — :production, :staging, :latest, and CalVer stamps like v2026.04.24.1 — are labels that can be moved between builds independently of the sha.

The list is sorted newest-first based on image push date. If the registry cache is warming (first load after a restart), the list may briefly show a loading state.

The LIVE pill

A green LIVE pill appears on the build whose image is currently running on the host. The launcher polls Docker every 10 seconds to determine what is actually running; the badge reflects runtime state, not deployment intent.

If no LIVE pill is visible, either no container is running or the running container was started without a sha-{commit} tag (for example, using :latest directly). In both cases, deploying a sha-tagged build through pw-launcher will restore the LIVE indicator.

The drift banner

A drift banner appears above the build list when the running build's sha and the registry's :production pointer have diverged. This is common and expected — it typically means a new build was promoted to :production in the registry but has not yet been deployed to the host.

The banner is informational. It disappears after you deploy the :production build, or after the :production tag is moved back to match the running build.

Expanding a build row

Clicking the expand arrow on any build row opens an action pane. The available actions depend on whether the build is currently live:

For the LIVE build:

• Rollback — starts a rollback to the previously-deployed build. See What is pw-launcher? for the difference between Full and Image-only rollback.

For any other build:

• Deploy — starts a deploy run for this build. The six-step sequence begins immediately and progress streams to the browser.
• Promote — move a category label to this build, with an optional CalVer stamp.
• Tags — add or remove arbitrary registry tags.

Promote and CalVer

The Promote dialog lets you move one of three mutable category labels — :staging, :production, or :latest — to a build. If the selected label is already on a different build, the dialog shows a warning before you confirm.

The CalVer input stamps an immutable version tag in the format v{YYYY.MM.DD.N} (for example, v2026.04.24.2). CalVer tags cannot be moved once assigned; re-assigning an existing CalVer to a different build is rejected with a collision error. The field is pre-filled with today's date and the next unused sequence number.

Leaving the CalVer field blank promotes the category label without stamping a version — useful for moving :staging during active testing before a build is ready to release.

Timeline tab

The Timeline tab shows the complete history of deploy and rollback operations for all stacks, newest first.

Reading a timeline row

Each row shows:

• Operation type — deploy or rollback
• Target — the sha that was deployed or rolled back to
• Status — the final outcome: DEPLOYED, ROLLED_BACK, or FAILED
• Started — timestamp of when the operation began

Expanding a timeline row

Clicking a row opens the step-by-step detail for that operation. Each of the six steps is listed with its name, outcome (success, failed, skipped), and timing.

If a step failed, the error message is shown inline. This makes it straightforward to answer "what exactly happened during last night's deploy?" without digging through container logs. A rollback triggered after a failed deploy also appears in the Timeline with its own step sequence.

Settings tab

The Settings tab shows the launcher's current stack configuration: what stacks are defined, which image repository each one watches, the Compose file and service name it targets, the health-check URL, and the backup type (Postgres or none).

The Settings tab is most useful for confirming that the launcher has loaded the correct configuration after an edit, or for sharing the current config during a support conversation.