XGen Release Tool is a keyboard-driven terminal dashboard for the two GitHub Actions pipelines behind a component deploy API: release (build images, tag, publish) and deploy (roll an environment to a released version). It has the same panels-and-shortcuts feel as btop.

Highlights

• Release and deploy in one screen. Press m to switch modes. A release is one per repo (no environment); a deploy targets development, staging or production (d / s / p).
• Profiles. Frontend and backend are managed separately. Each has its own ref, version and parameters per environment, plus a release block. Every edit shows a live preview of the exact request.
• Stops a dangerous duplicate release. The release workflow pushes images before it creates the git tag. Re-releasing an existing version would overwrite those images and then fail. The version field turns red when the tag already exists, and the release is blocked.
• Checks before anything is sent. Missing branches, unknown services and releases already in progress are blocked. You're warned about a version that isn't newer, a branch with no new commits, a partial release whose deploys would fail, or deploying a version that was never released.
• Confirm with a full summary. Releases ask you to type the version; production deploys ask you to type production.
• Release, then deploy. n suggests the next version after the latest GitHub release. When the release succeeds, P puts that version into the deploy form.
• Live run tracking. Each dispatch is matched to its GitHub Actions run, with status and per-job results. If a release pushed images but failed to tag, the run is flagged as a mismatch.
• Sessions renew themselves. Paste your Cognito refresh token once (the DevTools curl or response JSON works too). The tool renews the 1-hour id token before it expires or when the API returns 401, and asks again only when the refresh token itself expires.

Design decisions

• Nothing runs without an explicit confirm. Anything that can't be undone (a git tag, a GitHub Release, a production rollout) needs a typed confirmation.
• Checks come from how the workflows really behave, not generic rules.
• If a check can't reach GitHub, it becomes a warning rather than silently passing.
• Credentials stay on your machine: tokens are saved with 0600 permissions in the snap's own data folder. Access tokens are refused, because the API needs the id token.
• Config, token and run history live in ~/snap/xgen-release-tool/common/, so they survive snap updates. Press o to edit the config in nano from inside the app.

Snap note: strict confinement can't run the gh CLI. In the snap, the tag and branch checks become warnings and run status comes from the API endpoint. Install the tool with uv tool install for full GitHub checks.

Press ? inside the app for every keyboard shortcut.