Dockerize the Godot Engine repository to simplify local development and contribution

[Ayush41]

Describe the project you are working on

I propose adding a Dockerfile (and optionally a docker-compose setup) to the Godot Engine repository to simplify local development, testing, and contribution. This would allow developers to build and run Godot in a consistent, containerized environment — especially useful for contributors on Windows or macOS, or those new to compiling from source.

Describe the problem or limitation you are having in your project

Setting up a local development environment for contributing to the Godot Engine can be time-consuming and error-prone — especially for first-time contributors or developers on non-Linux platforms. The process requires:

• Manually installing platform-specific build tools and dependencies.

• Understanding and configuring the build system.

• Handling cross-platform inconsistencies (e.g., macOS vs Linux vs Windows).

• Repeating the setup for different target platforms (e.g., Linux, Web, Android).

This setup friction can discourage new contributors and make local development harder to maintain across machines or team members. Additionally, contributors may face version mismatches, build issues, or conflicting environments when switching between projects or machines.

• A Docker-based solution would encapsulate all necessary dependencies and steps, making it easier to:

• Onboard new contributors quickly.

• Ensure consistent builds across platforms.

• Reproduce issues or test patches in clean environments.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Adding a Dockerfile to the Godot Engine repository allows developers to build and run the engine in a pre-configured container. This eliminates the need for manual setup of dependencies and build tools, ensures environment consistency across platforms, and makes it much easier for new contributors to get started quickly with development and testing.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

✅ Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

A Dockerfile will be added to the root of the repository to define a consistent build environment using Node.js, SCons, and system dependencies. Contributors can use it to build and run the engine without configuring their local machine.

Example Dockerfile workflow:

# Build the Docker image
docker build -t godot-dev .

# Compile the engine inside the container
docker run --rm -v $(pwd):/godot godot-dev scons platform=linuxbsd

# Run the built editor
docker run -it --rm -v $(pwd):/godot godot-dev ./bin/godot.linuxbsd.editor.dev.x86_64

This approach enables anyone to build Godot locally without setting up toolchains, solving compatibility and setup issues across different OS environments.

If this enhancement will not be used often, can it be worked around with a few lines of script?

While setting up the build environment can be scripted, it still requires manual installation of dependencies across platforms, which varies between Linux, macOS, and Windows. A Docker-based setup offers a single, consistent, cross-platform solution that scripts alone can’t fully achieve. It reduces environment-related issues and streamlines onboarding, especially for first-time contributors or CI/CD pipelines.

Is there a reason why this should be core and not an add-on in the asset library?

Yes. This enhancement is meant for contributors working on the Godot Engine source code, not for game developers using the editor. Since it improves the development workflow for the engine itself, it belongs in the core repository—not the asset library, which is focused on runtime features and game development tools.

[KoBeWi]

Godot is probably the easiest to build C++ project, even on Windows. You only need to install MSCV, Python+Scons and then run scons in the main directory. No additional configuration or buildsystem shenanigans are needed.

Understanding and configuring the build system.

What exactly do you need to understand/configure? You only need to copy-paste a command from the documentation.

Handling cross-platform inconsistencies (e.g., macOS vs Linux vs Windows).

Are there any? AFAIK, once you setup the environment, the building process is the same, i.e. run scons.

Repeating the setup for different target platforms (e.g., Linux, Web, Android).

Beginner contributors need to build only for a single platform.

It's not like I'm opposed, if it just involves adding one file, I'm just confused about the premise of this proposal. It also assumes that someone already has Docker installed and ready to use, otherwise you trade build environment setup for Docker setup.

[Calinou]

godotengine/godot#83791 implements this by adding a development container.

I'm not opposed to it if the solution is self-contained, but we should make sure the container is only used to build Godot by default, not to run it. Godot requires GPU acceleration to work, and this has historically been a hurdle in Docker and other containerized environments (including WSL). This also means you wouldn't be able to use a debugger within container either, which would reduce the interest in the development container.

[Ayush41]

Thanks for the thoughtful feedback!

You're right — Godot's build system is definitely one of the most accessible C++ projects to compile, and the docs do a great job. This proposal isn't meant to replace that simplicity, but rather to offer:

• A quick-start, consistent build environment for contributors who prefer containerization.
• A portable option for CI/CD, cloud-based development, or constrained environments.
• An optional workflow for those who already use Docker or Dev Containers in their stack.

I also appreciate the reference to #83791 — that Dev Container setup looks great and aligns with the core idea of this proposal. I’ll review that PR in more detail and look into how Docker-based workflows can complement (rather than duplicate) that effort — particularly for headless builds and contributor onboarding.

To clarify: I completely agree that running the editor in Docker (especially with GPU acceleration and debugging needs) is out of scope and not ideal. My focus was only on build-only containers, as mentioned.

Happy to adjust or close this if maintainers consider it covered by #83791 — otherwise, I’d love to help contribute toward polishing a streamlined Docker-based setup alongside it.

[CarpenterBlue]

I am pretty sure this is an AI spam.

Reasons:
Affirmative reply when challenged in the first sentence.
Use of Em-dash (—) I have seen only 3 real people use it in their life pre-AI.
The wordiness and over clarification.
Eagerness to adjust.

I am hiding this reply as off-topic but I think it was worthwhile to say this.