Limits of headless server build size reduction in Godot 4.x

Direct answer

There is no universal maximum safe percentage for reducing a Godot 4.x dedicated server binary. The safe floor is the smallest build that still contains the transitive dependency closure of your project: the core scene, script, and resource stack; the physics backend you rely on; the multiplayer networking stack; and every module required by your scenes, scripts, resources, or GDExtensions. Idle CPU is not proportional to binary size. A headless server with no connected clients should sit near idle; each additional client adds a small increment for packet processing and scene replication, not a large baseline shift caused by stripping or module removal.

Likely explanation vs. confirmed facts

Likely explanation: stripping debug symbols and using a release headless export are usually low-risk for gameplay logic. They primarily remove diagnostics and rendering/display paths, leaving simulation behavior intact. This is why they can cut file size substantially without affecting deterministic physics.

Confirmed facts: selective module disabling is the risky step. Disabling physics, scripting, scene/resource, navigation, or networking-related subsystems can break deterministic simulation or replication. Determinism is build-specific: results can differ across Godot 4.x minor versions, compiler flags, target architectures, or physics backends. Keep the exact same engine build for all server instances if you need lockstep or rollback consistency.

Steps needed for this case

1. Build two server binaries from the same commit: a release headless build with symbols kept, and the stripped/module-reduced build. Compare sizes with ls -lh.
2. Before disabling any module, generate a dependency inventory: scan scenes, scripts, and resources for engine classes, and list all GDExtension dependencies. Disable one module at a time, then run an import/load smoke test plus a short headless match.
3. Measure idle CPU with 0, 1, 8, and 64 clients using the same OS process monitor over a fixed interval. Record packet rates and physics tick counts alongside CPU so per-client cost is attributable.
4. Verify determinism by running the same fixed-seed inputs on multiple instances and comparing state hashes or selected simulation outputs. Repeat after any engine upgrade, compiler flag change, or physics backend change.

Missing diagnostic detail

Does the server use GDExtension, Mono/C#, or custom C++ modules? If yes, module disabling becomes ABI/runtime-sensitive. You should keep an unstripped debug build and complete the dependency inventory before cutting modules, because removing a module that a native extension links against can produce runtime load failures rather than clean compile errors.