Run history, deployments & rollback
The Deployments panel: a log of every run and its phases, a per-channel record of what version is live, post-deploy health checks, and rollback for the channels that support it.
Last updated 2026-07-25
The Deployments panel is AppRelay's memory of what you've run and shipped. It has two tabs: Runs, a log of every build, test, run, and release; and Deployments, a per-channel record of what version is live where. Both are kept locally on your own computer — and once you've paired the mobile companion, the Runs list is browsable from your phone too.
Run history
Every run AppRelay performs — whether you started it from the desktop, the phone, the CLI or a trigger — is recorded as it happens. The Runs tab lists the most recent runs newest-first, each showing its lane, where it came from, how many steps completed, when it ran, and a status badge.
Filter the list by lane, source (desktop, CLI, phone, or a specific trigger kind), outcome, or a date window to zero in on, say, last week's failed webhook builds. Click any run to open its detail: the outcome and how long it took, then the full step timeline — each step with its command and exit code, any manual approval gates, and what shipped. From there, Re-run rebuilds that run's lane through the queue; it repeats the build only and never re-ships, so a repeat can't publish by accident.
A run moves through a small set of phases:
- Queued → Preparing → Running
- Waiting in the run queue, setting up, then executing the recipe steps.
- Awaiting manual
- Paused on a step that needs you — a confirmation or a manual action — before it continues.
- Finalizing → Succeeded / Failed / Cancelled
- Wrapping up, then the terminal result.
- Crashed
- Marked automatically if AppRelay quit mid-run, so an interrupted run never looks like it's still going.
Each run keeps an ordered event log of its steps and their outcomes. As with the live log, commands and secrets are redacted before anything is written to disk, so the history can't leak a token. AppRelay keeps the most recent runs and prunes the oldest automatically.
Deployments — what's live where
When a release ships a version to a channel, AppRelay records a deployment. The Deployments tab groups these by channel and marks the current version on each with a LIVE badge, with earlier versions listed beneath it. At a glance you can answer “what's on the App Store / on npm / on the server right now?” — and see who shipped it and when.
Artifacts
Each ship also captures its build artifact — the .dmg, .ipa, .aab, and so on. AppRelay keeps a copy under its Application Support folder and shows a Reveal in Finder affordance on the deployment (and in the run's detail), so you can grab exactly what you shipped later. Retention is a keep-newest-N / max-age policy you set in Settings → Artifacts (or turn copying off, in which case only the original build path is remembered). Old copies are pruned automatically so they don't pile up.
Health checks
A distribution can carry an optional verification so a deploy doesn't just say it worked — it's checked. When you ship from the app, AppRelay runs the check and stamps the deployment with a health badge:
- Checking
- The verification is in flight (it retries a few times before giving up).
- Healthy
- The check passed.
- Unhealthy
- The check failed — hover the badge for the reason.
- Unverified
- No check was configured for that channel.
A check is either an HTTP probe (fetch a URL, expect a status, and optionally require the response to contain the version you just shipped) or a shell command judged by a pass signal — the same pass-signal mechanism recipes use.
Rolling back
Whether a channel can be rolled back depends on the channel:
- Reversible channels — a Sparkle appcast, your own server, and web hosts like Vercel, Netlify, S3, Cloudflare Pages, and GitHub Pages — can be re-shipped at an earlier version. On a live deployment, AppRelay offers a Roll back… action that executes the revert: it checks out the prior version's git tag into an isolated worktree, rebuilds it, and re-ships it to that channel — your working tree is never touched — then records the rollback so the earlier version shows live again.
- Irreversible channels — the App Store, Google Play, npm, and git tags — can't unpublish a version. AppRelay says so plainly and points you at the real fix: ship a higher version (or deprecate the bad one).
v1.2.3) in the project's repo; if there isn't one, or you reverted outside AppRelay, choose Record a manual rollback to note it in the history. Irreversible channels (App Store, Play, npm, git tags) can't be un-published, so AppRelay explains the hotfix path instead.Kept local, per machine
Run and deployment history live in AppRelay's app-data folder on this computer. They survive quitting and relaunching, and — like triggers — they are not included in a .relay archive. Importing a project on another computer gives you its configuration and secrets, but starts with a clean history.
Next steps
- Cutting a release — where deployments come from
- Scheduled, watch & webhook triggers — automate the runs that fill this history
- Distribution channels reference — which channels are reversible