Checks go.mod before you tag: missing /vN major version suffix, go line older than the two supported Go releases, toolchain below go, local replace, require path/version mismatch. Each finding has the fix line. Runs entirely in your browser — nothing is uploaded.
Same engine as the VS Code extension, byte for byte.
A dated release-gate report for each tag with the go.dev rule cited next to every line, plus a CI exit code that stops the tag.
One payment, one licence key for this tool. The key is shown right after payment.
One hour of a software developer at the US median wage is $65.38 (BLS OEWS, May 2025)
Buy the full version — $29· ReadyStack
Real numbers from this tool, line by line.

6 go.mod fixes before tagging: that is what go.mod Release Gate found in one sample go.mod from a Go library maintainer about to push v2, and each of the 6 came with the exact line to write instead.
If you maintain a Go library or CLI that other people install with go get, the go.mod file is the part of your release that your users run, not you. Four kinds of mistakes in it break their build or quietly leave them behind, and none of them show up when you build inside your own repository.
The first is the major version suffix. The Go Modules Reference says: starting with major version 2, module paths must have a major version suffix like /v2 that matches the major version. If your go.mod still says module github.com/acme/ratelimit and you push v2.0.0, a module that has a go.mod file cannot take that tag. Without a go.mod it would resolve as +incompatible. The fix is one line, module github.com/acme/ratelimit/v2, plus updating your internal imports. The sample go.mod had already retracted v2.0.1, which tells the checker that v2 tags exist on a path without the suffix.
The second is the go line. Go's release policy is that each major release is supported until there are two newer major releases. Go 1.27 came out on 2026-08-19, so from that day Go 1.26 and Go 1.27 are supported and Go 1.25 gets no more security fixes. The sample still said go 1.24. The checker flags it and prints go 1.26.0 as the fix. It keeps the release dates from go.dev in the engine, so the answer depends on the date, not on what a chatbot remembers.
The third is the toolchain line. The toolchain version cannot be less than the go line. The sample had toolchain go1.23.4 under go 1.24, which the go command rejects. Fix: toolchain go1.24.0, or delete the line.
The fourth is replace. The reference says replace directives only apply in the main module's go.mod file and are ignored in other modules. The sample had replace github.com/acme/shared => ../shared. It builds on your laptop and it is ignored on everyone else's machine. The checker tells you to publish the shared code as a module or delete the line before tagging.
Then there are the require lines. github.com/google/go-github v45.2.0 has no /v45 in the path, so the go command rejects it; the fix is github.com/google/go-github/v45 v45.2.0. github.com/acme/queue/v3 v2.4.0 has a path that says v3 and a version that says v2; the fix is github.com/acme/queue/v2 v2.4.0. A +incompatible dependency is listed as information, because the go command may upgrade it across a breaking major.
That is 12 rules in total, each tied to a section of go.dev. The fixed go.mod gives 0 findings.
Why not ask a chatbot? Because it answers from training data. Ask which Go versions are supported and you may get an answer from a year ago. go mod tidy will not complain about a local replace or an old go line either, and it does not know which tag you are about to push.
What does it cost to get wrong? A rejected v2 tag usually takes a maintainer an hour or more to track down, and one hour of a software developer at the US median wage is $65.38 (BLS OEWS, May 2025). Worse, your users see the error before you do.
The free version runs in VS Code and in the browser with no key. Paste a go.mod, read the findings, copy the fix lines. The full version adds a dated release-gate report per tag with the go.dev rule cited next to every line, and a CI exit code that stops the tag when a finding is left.
It reads a go.mod file line by line against 12 rules from the Go Modules Reference and the Go release policy. Each finding gives the line number and the exact replacement line: a missing /v2 suffix, a go line older than Go 1.26, a toolchain below the go line, a local-path replace, or a require whose path and version disagree.
Go library and CLI maintainers who are about to push a release tag, especially a first v2.0.0 tag. If other people run go get on your module, the lines it flags are the ones that break their build or leave them on a Go release that no longer gets security fixes.
A chatbot answers from training data and often names Go versions that are already out of support; Go 1.25 lost support on 2026-08-19 when Go 1.27 shipped. go mod tidy does not complain about a local replace or an old go line, and it cannot know which tag you are about to push.
Free: all 12 rules, every finding with its line and fix, in VS Code and in the browser, with no key. The full version ($29, one payment) adds a dated release-gate report for each tag with the go.dev rule cited next to every line, and a CI exit code that stops the tag.
Tracking down a rejected v2 tag by hand usually costs a maintainer an hour or more. One hour of a software developer at the US median wage is $65.38 (BLS OEWS, May 2025). The free checks cost nothing, and the full version is $29 once for one person or team seat.
One question, answered by the person who built it. Your email only if you want the answer sent.