Building Godot

Choose a build

Select an engine version, platform, architecture, target, precision, and optional modules. Modules are compiled into the engine; they are not runtime addons.

Platform value	Architectures accepted by this project	Toolchain
linuxbsd	x86_64, arm64	Native GCC / Linux cross-compiler
windows	x86_64	mingw-w64
macos	x86_64, arm64	osxcross plus a supplied Apple SDK

Windows ARM64 is rejected because the shipped toolchain does not support it. The macOS validation entries do not establish that an SDK or working image is installed; see macOS SDK setup.

Targets are editor, template_debug, and template_release. Precision is single by default, or double. Use matching engine/template configurations for your project.

Browser workflow

1. Choose a catalog engine and review its available modules and options.
2. Select modules and their required dependencies. Public builds use catalog releases rather than arbitrary repository refs.
3. Submit the build. An anonymous deployment requests human verification when necessary; a legacy deployment uses a token session.
4. Follow the build detail page until completion, then download its artifacts.

Public typed options cover optimization, LTO, debug symbols, 3D, renderers, and selected built-in modules. The backend schema determines which values are accepted. A catalog change can produce 409; reload and review the selection before submitting again. Accepted builds retain a catalog snapshot, and preparation records source commits for retries. See immutable build configuration.

Public logs show sanitized progress categories. Administrators can access raw diagnostic logs. Browser ownership permits cancellation in anonymous mode; simply knowing a build ID does not grant cancellation authority.

CLI against a legacy server

export GBB_SERVER=http://localhost:8080
export GBB_TOKEN='replace-with-your-issued-token'
./bin/gbb modules --godot 4.4-stable
./bin/gbb build --godot 4.4-stable --platform linuxbsd --dry-run
./bin/gbb build --godot 4.4-stable --platform linuxbsd --follow=false
./bin/gbb list --limit 10
./bin/gbb status --json BUILD_ID
./bin/gbb fetch --out ./out BUILD_ID

Replace BUILD_ID with the returned ID. Flags must precede positional IDs. --dry-run validates and prints the spec without checking server catalog availability or compiling. By default, build follows logs and downloads the result; --follow=false returns after submission.

Use --modules module_a,module_b to select catalog modules. The CLI also accepts name@ref overrides in its legacy/local workflow. --only-selected disables default engine modules and can produce a substantially different engine; required functionality must still be enabled.

Remote token workflows do not work against the anonymous/Authelia public deployment. Use its browser UI, or use --local for local compilation. Run ./bin/gbb COMMAND -h for each command's flags.

Build states

The normal sequence is queued → preparing → building → packaging → succeeded. Preparation resolves and assembles sources; building runs SCons; packaging collects and publishes artifacts. Failures end in failed, cancellation in canceled. Retention can later mark a successful build expired after its artifacts are removed.

A queued build has been accepted but has not started compiling. A verification session expiring does not cancel an admitted build. Public quotas count accepted failed and canceled builds too.