Shipping and updating

Commands use the installed sdk and configured project from Getting started. Export the exact game you tested, then treat an SDK change as a new build rather than reusing old acceptance.

Choose a native profile

debug is the default for run and normal editor work. Use release for optimized native code, and pass the profile on every public launch/test:

"$sdk/bin/gododin" build --project-root "$project" --profile release
"$sdk/bin/gododin" run --project-root "$project" --profile release --headless \
  --script res://tests/oracle.gd

Profiles have separate accepted state. Read GODODIN_RUN_IDENTITY to confirm the actual profile and artifact. The example harnesses' GODODIN_PROFILE convention is documented in their shared entry point; it does not replace the public CLI's --profile flag.

Export the native closure

Use Project > Export and your ordinary Godot preset. Gododin prepares the matching native debug/release build and packages its authenticated libraries; Godot keeps the preset's application identity, signing, icons and filters. Its Export With Debug checkbox also selects the native debug/release profile. Native build errors stop application export. Repair the source and export again; the previous accepted native image is never substituted. Exporting a native application requires its native target toolchain as well as Godot templates. Keep addons/gododin/native.gdextension in the preset's resources. For a preset that exports selected scenes, add *.gdextension to the include filter in Resources. A matching exclusion blocks export with a correction in Godot.

For CI, select that same preset explicitly:

"$sdk/bin/gododin" export --project-root "$project" \
  --profile release --output /absolute/output/RipplePond.app --preset "macOS"

Full application export carries native libraries; a data pack alone does not. The older no-preset CLI route below retains its generated preset, authenticated template and package-inspection contract for existing automation.

With the export tools configured, produce a debug build for testing and a release build for players. These examples use macOS app bundles:

"$sdk/bin/gododin" export --project-root "$project" \
  --profile debug --output /absolute/output/RipplePond-debug.app
"$sdk/bin/gododin" export --project-root "$project" \
  --profile release --output /absolute/output/RipplePond.app

Export builds current source, uses that profile's accepted snapshot and verifies its native dependency closure. There is no last-known-good export. Choose an output path for your project's target: .app on macOS, .exe on Windows, or an executable on Linux. Export uses the target and toolchain from the project's configuration and lock.

Players receive the Godot runtime, game content and matching Host/project native libraries. On macOS the .pck lives in Contents/Resources and both native libraries in Contents/Frameworks. Declared static foreign archives are already linked into the image. Any admitted dynamic dependencies must travel with the game and pass the artifact manifest; do not assume an external library on your development machine will exist for players. The compiler, SDK, CLI, OLS and editor/baking tools are build-time dependencies, not player requirements.

Run both exported applications and check the scenario and clean shutdown. Test the release package on a machine with only the player's dependencies. On macOS, export applies ad-hoc signing; apply your distribution signing and notarization before delivery. Check your store's packaging requirements when distributing through a store.

Move an SDK

For the Godot-first path, open Connection settings, select the SDK in its new location and choose Connect. The same ignored authority link and tool paths are revalidated. Existing CLI automation can use the equivalent commands below.

Save your project and close its authoring editor normally before moving the immutable SDK. Moving it invalidates the old project-local link; invoke attach from its new canonical location, then reopen the editor:

new_sdk="/absolute/new-location/gododin-sdk"
"$new_sdk/bin/gododin" attach --project-root "$project"
"$new_sdk/bin/gododin" doctor --project-root "$project"
"$new_sdk/bin/gododin" editor --project-root "$project"

This authenticates the same project lock and updates only ignored authority state, plus derived language-tool configuration when enabled. It does not put an absolute SDK path into committed configuration. Repeating attach is idempotent. Set sdk="$new_sdk" for subsequent commands.

Upgrade deliberately

In Godot, select the new same-engine SDK in Connection settings and choose Use selected SDK release. This is the explicit lock-adoption action; review and commit its lock change. Rebuild and retest your application and exports. The equivalent CLI procedure follows.

For a new SDK release targeting the same exact engine, save your project and close its authoring editor normally. Use the new release's CLI to adopt its lock and reopen the editor:

new_sdk="/absolute/path/to/new-gododin-sdk"
"$new_sdk/bin/gododin" attach --project-root "$project" --adopt-lock
"$new_sdk/bin/gododin" doctor --project-root "$project"
"$new_sdk/bin/gododin" editor --project-root "$project"

--adopt-lock atomically adopts the SDK's exact bytes and preserves the previous lock at .gododin/previous-lock.toml (a later adoption replaces that single backup). Reopening through editor refreshes its owned add-on inventory. Review and commit the lock change, set sdk="$new_sdk", rebuild each profile and rerun your application test and exports. Gododin does not rewrite your authored source during an upgrade; review any API changes before rebuilding.

For acquisition, changed toolchain prerequisites or an engine-version change, follow the separate setup and migration instructions.

Return to Getting started or The development loop.