Download AlphaGSM for your system.

Pick the build that matches this computer

Release files are named alphagsm-VERSION-PLATFORM-ARCH, with .exe on Windows. VERSION is MAJOR.MINOR.PATCH without a leading v. Each file is published with a sibling .sha256 checksum. The suggestion below uses this browser's platform. The other four builds stay listed.

These baselines mean the executable was built and smoke-tested on that runner. They do not mean every game server in the catalogue runs on that operating system. Ubuntu 24.04 remains the full game-server lifecycle baseline. Linux builds need a compatible glibc. Alpine and musl are not covered. Windows ARM64 is not a build target. Representative Minecraft checks on Windows and macOS do not extend the whole catalogue to those platforms.

Source install and the Docker manager remain documented in Getting started and do not wait on a release asset.

Check the SHA-256 checksum

The build writes alphagsm-VERSION-PLATFORM-ARCH.sha256 beside the executable. On Windows and macOS the release job signs the binary first and then rewrites that checksum, because signing changes the bytes. Compare the file you downloaded with the checksum from the same release.

sha256sum -c alphagsm-VERSION-linux-X64.sha256

On macOS:

shasum -a 256 -c alphagsm-VERSION-macos-ARM64.sha256

On Windows PowerShell, compare the two values yourself:

Get-FileHash .\alphagsm-VERSION-windows-X64.exe -Algorithm SHA256
Get-Content .\alphagsm-VERSION-windows-X64.exe.sha256

The checksum file is two spaces between the digest and the file name, which is the usual sha256sum layout. A mismatch means you should stop. Do not rename the file before the check. The checksum line contains the published file name.

Check the signature that the release job creates

Linux release builds are checksummed and are not Authenticode-signed or Apple-signed. Windows releases are Authenticode-signed with a timestamp. macOS releases are code-signed, and the release job waits for Apple notarization of that build. The published macOS check in the repository is codesign, not a separate staple step.

signtool verify /pa .\alphagsm-VERSION-windows-X64.exe
codesign --verify --deep --strict ./alphagsm-VERSION-macos-ARM64

A tag release also creates a GitHub build-provenance attestation for the uploaded files. With the GitHub CLI:

gh attestation verify alphagsm-VERSION-linux-X64 --repo SectorAlpha/AlphaGSM

scripts/verify_binary.py in the repository is the maintainer acceptance test. It runs an isolated executable through a Minecraft lifecycle. It is not the command operators use to check a download. scripts/sign_release.py is the CI signing step, and it requires release credentials that are not in the repository.

Run the executable you verified

On Linux or macOS, rename the verified file to alphagsm if you want the short command, mark it executable, and ask for the version:

chmod +x alphagsm
./alphagsm --version
./alphagsm --help

On Windows, rename it to alphagsm.exe and run .\alphagsm.exe --version from PowerShell. Settings live in ~/.alphagsm on Linux and macOS, and in %LOCALAPPDATA%\alphagsm on Windows. The executable directory can be read-only. An optional alphagsm.conf beside the executable supplies defaults and is not required for the first run.

After you trust the file, the Minecraft-shaped first server is still the getting-started path. Read that game's license before accepting it. Later, ./alphagsm self-update --check and ./alphagsm self-update verify the downloaded replacement checksum before swapping the executable. The directory must be writable. A failed update keeps or restores the previous file.

The upstream detail is Standalone binaries. Platform limits for individual games stay on the project status page.

Frequently asked questions