Releases and CI Builds

Every FYRwall release is built automatically by CI. A release ships three

ways to install — installer script, standalone tarballs, and container

images — plus SHA-256 checksums for everything.

What a release contains

Every GitHub Release for vX.Y.Z carries these assets:

Supported architectures: amd64, arm64, arm, 386, ppc64le, s390x, riscv64.

Docker images (amd64 + arm64) are pushed to

ghcr.io/potenfyr-studios/fyrwall in parallel by the Docker workflow.

How CI builds a release

Same-version replace semantics

The release pipeline is idempotent — it never creates duplicate releases:

• Re-pushing a version tag (v0.1.0 again, or a moved tag): the existing

release for that tag is deleted (assets included; the git tag itself is

kept) and recreated from scratch. Builds and changelog are fully replaced.

• Push to `master` while the VERSION file is unchanged: all release

assets are rebuilt and clobbered in place (--clobber), and the release

notes are regenerated from CHANGELOG.md plus a single build line naming

the commit. Repeated refreshes never accumulate build lines.

• Push to `master` with no existing release: nothing is published. A new

release always requires a version-bump tag; CI logs a notice and exits

cleanly.

• Manual re-run: use Re-run all jobs on a past run or the workflow's

Run workflow button (workflow_dispatch).

Installing from a release

Installer script (recommended)

curl -fsSL https://github.com/PotenFYR-Studios/FYRwall/releases/latest/download/install.sh | sudo shCopy

Review-first variant:

curl -fLo install-fyrwall.sh https://github.com/PotenFYR-Studios/FYRwall/releases/latest/download/install.sh
less install-fyrwall.sh
sudo sh install-fyrwall.shCopy

The installer resolves the latest release, downloads the tarball for your

architecture, verifies it against SHA256SUMS and installs. Pinning,

offline and air-gapped installs are documented in Installation.

Manual tarball install

cd <release download directory>
grep "fyrwall_<version>_linux_<arch>.tar.gz" SHA256SUMS | sha256sum -c -
tar -xzf fyrwall_<version>_linux_<arch>.tar.gz
sudo install -d -m 0750 /etc/fyrwall
sudo install -m 0755 fyrwall_<version>_linux_<arch>/fyrwall /usr/local/bin/fyrwall
sudo install -m 0640 fyrwall_<version>_linux_<arch>/config.example.yaml /etc/fyrwall/config.yaml
sudo install -m 0644 fyrwall_<version>_linux_<arch>/packaging/systemd/*.service /etc/systemd/system/
sudo systemctl daemon-reloadCopy

Container images

docker pull ghcr.io/potenfyr-studios/fyrwall:latest
# pinned release tag, pushed on version-bump tags only:
docker pull ghcr.io/potenfyr-studios/fyrwall:v0.1.0Copy

See Docker for run commands and the server + agent topology.

Verifying a release

Every release asset is covered by SHA256SUMS. Verify a single downloaded

asset (the same pattern the installer uses):

grep "fyrwall_<version>_linux_<arch>.tar.gz" SHA256SUMS | sha256sum -c -Copy

To verify everything at once, download all assets into one directory first:

sha256sum -c SHA256SUMSCopy

The installer verifies the tarball checksum automatically and refuses an

unverified install. See the security model for how FYRwall

handles trust boundaries, and Updating for the in-tool update

path.

Version, tag and image matrix

The raw-version image tag (:0.1.0) is pushed on every build, so the

rolling :latest and version tag always track the tip of master, while

:vX.Y.Z pins an exact release.

Next: Installation · Updating