Deployment

A version tag builds native release archives, verifies the application build, publishes downloadable assets and installers to GitHub Releases, and deploys the Linux production binary when application code changed. Static product pages deploy separately.

Pipeline triggers

• Tag release Pushing a v* tag packages every supported platform and creates or updates the matching GitHub Release.
• Production deployment When the tagged diff includes an application path, the GitHub-built Linux x86_64 binary is deployed and io-gateway.service is restarted. A documentation-only tag still publishes release assets but skips production deployment.
• Pages deployment Pushes to master or main deploy GitHub Pages when site/ or the Pages workflow changed.
• Manual dispatch A manual run can validate and deploy the current checkout, but publishing a GitHub Release requires a pushed version tag.

Published release assets

Every release also includes SHA256SUMS, install.sh, and install.ps1. The checksum file covers every archive and both installers. Each archive contains io-gateway, iogw, and config.example.json (with .exe names on Windows).

The installer URLs use GitHub’s releases/latest/download/ endpoint. They become available after a version tag has completed the release workflow successfully.

Tag release flow

1. 1
   Push the finished commit and a version tag.

   For example: git tag vX.Y.Z, then git push origin vX.Y.Z.

2. 2
   Validate the application.

   When application paths changed, the workflow checks formatting, dashboard JavaScript syntax, tests, and the Linux release build.

3. 3
   Build six native archives.

   GitHub Actions builds Linux x86_64/ARM64, macOS Intel/Apple Silicon, and Windows x86_64/ARM64 binaries on their matching runners.

4. 4
   Publish the GitHub Release.

   The workflow collects the archives, installers, and SHA256SUMS, then creates the tag’s Release or replaces matching assets on an existing Release.

5. 5
   Deploy production when applicable.

   The server receives the GitHub-built Linux artifact rather than a binary from a local checkout. The deployment keeps the previous binary as a backup, installs the new version, restarts io-gateway.service, and checks readiness.

Production checks

curl http://127.0.0.1:8319/health
curl http://127.0.0.1:8319/ready

Rollback

Keep the previous binary during deployment. If readiness fails after restart, restore the previous binary, restart the service, and check troubleshooting before creating a new tag.