One YAML file can replace a release-script pile
GoReleaser 2.18 takes a SemVer tag and .goreleaser.yaml, then moves through four named stages: defaults, building, publishing, and announcements. A basic run can compile binaries, put each target in an archive, calculate release material, and create a release on GitHub. The current documentation covers Go, Rust, Zig, JavaScript, TypeScript, and Python. That range makes it useful when a project has outgrown a shell script copied between repositories.
The appeal is consistency. A maintainer can run goreleaser release --snapshot --clean before a tag, validate the file with goreleaser check, and use goreleaser healthcheck to look for missing tools. GoReleaser 2.18 also writes successful publication actions to a GitHub Actions job summary. The same configuration can describe archives, Docker images, Homebrew entries, Scoop manifests, Nix packages, AUR packages, signatures, and software bills of materials.
The free binary covers the common path, while Pro owns specialist work
The v2.18.1 repository is MIT licensed, and its free binary handles a substantial release pipeline. It can build multiple targets, create archives and packages, publish source-control releases, push container images, and update several package channels. For a typical open-source command-line tool that ships GitHub assets plus a Homebrew formula, the free edition is a credible starting point.
GoReleaser Pro is a separate paid, closed-source distribution. Its current feature list includes split and merge builds, macOS .pkg, .app, and .dmg output, Windows MSI and NSIS installers, offline licenses, release verification, and several advanced publishing controls. That line matters before adoption. If your release design depends on running platform-specific jobs separately or producing native installers, price and license terms belong in the first estimate, not the week before launch.
What happened when we ran it
Our sandbox cloned commit 2ab3100 into an unprivileged Debian container with 3 CPUs and 8 GB of RAM. Installation succeeded in 205 seconds and pulled 931 packages. The build also succeeded, taking 134 seconds. The checkout contained 1,190 files, roughly 103,511 source lines, and used 7 MB before the installed dependencies.
Tests failed with exit code 1 after 117 seconds. The reported result was 154 passed and 23 failed out of 177. The final lines show successful checks for gzip, tar, tar.gz, tar.xz, tar.zst, xz, zip, build, config, context, and healthcheck packages, followed by a bare FAIL. Those lines do not expose an error message for the 23 failures, so blaming a missing package, network call, or flaky test would be guesswork.
The repository has 15 CI workflow files and a Dockerfile. It has no directory literally named tests, which is ordinary for Go code because tests commonly sit beside the packages they exercise. The failed suite still counts. Before putting GoReleaser in charge of a real tag, reproduce the run on the same version and inspect the complete failure output.
The release runner holds the keys to every destination
The v2.18.1 quick start requires a GitHub token that can write repository contents. GitHub Container Registry also needs package-write access, while other registries, signing systems, and storage targets bring their own credentials. GoReleaser's threat model names source code, artifacts, signing keys, repository credentials, and CI runners as critical assets. That is an accurate description of the blast radius: the tool sits where source becomes something users install.
Keep snapshot and build-only checks separate from the credentialed release job. Pin the GoReleaser version, review configuration changes, restrict who can trigger tags, and grant each publishing token only the access its destination needs. The project's security policy supports only the latest stable version. On September 5, 2026, v2.18.1 included dependency security updates and fixes across archives, Git, GitLab, Docker, Chocolatey, and signing behavior.
Two open packaging reports deserve targeted preflight checks
Open issue 6739 shows a signed MSIX returning HashMismatch from PowerShell's Get-AuthenticodeSignature. The report includes a reproducible package and command sequence, but it does not yet establish a cause. A Windows release that depends on MSIX should verify the produced package on Windows before publication instead of treating a completed signing step as proof.
Homebrew has another sharp edge. Issue 6870 reports that GoReleaser 2.18.0 emits a deprecated postflight stanza for cask install hooks. The generated file is overwritten on the next release, so editing the tap by hand does not stick. A related pull request was active in September 2026. Teams using cask hooks should test the generated formula against the current Homebrew version and watch that fix.
September maintenance is active, and the 23 failures still set the trial bar
GitHub recorded a push on September 15, 2026, ten days after the v2.18.1 release. The repository had 16,050 stars and 16 open issues and pull requests when fetched. Several open pull requests had September updates, including work on archive templates, custom TLS uploads, cask hooks, and Alpine packages. This is active maintenance, while the combined open count should not be mistaken for a bug total.
GoReleaser earns a trial when release scripts have become their own small product. Its configuration and docs give one owner a clear place to reason about artifacts and destinations. Our 134-second build says the code compiled in the supplied sandbox; the 23 failed test results say adoption should stop short of trust until your pinned version, release targets, and full suite pass together.