godot-bevy: running Bevy ECS logic inside the Godot editor

What godot-bevy is for

godot-bevy brings Bevy's ECS to Godot, allowing you to write high-performance game logic in Rust while leveraging Godot's editor and rendering capabilities.

That division of labour is the whole idea. Godot keeps the things it is good at, the scene tree, the editor, the renderer, the asset pipeline, and the parts of a game that are about authoring content rather than about systems. Bevy brings the systems model, with entities, components, queries and schedules, which is the part where a Rust programmer tends to want a data oriented approach rather than a node tree.

The library is published on crates.io as godot-bevy, with API documentation on docs.rs and a separate book at bytemeadow.github.io/godot-bevy-book. The documentation is described as covering installation and setup, core concepts and architecture, the plugin system, the transform system and physics, input handling, and examples and best practices.

The users are Godot users who want Rust in the loop, and Bevy users who want to keep Godot's editor. The project is a single developer effort by the look of the credits and the Discord badge, with a stated minimum Rust version of 1.88.0, and it is distributed under the terms of both the MIT license and the Apache License, Version 2.0.

The project also carries a sponsor acknowledgement for Blaze, which provides high-performance Linux and Apple Silicon macOS runners for GitHub Actions and is credited with greatly reducing the automated build times.

The dependency set and the Bevy features it disables

Adding the library to a project is three lines in Cargo.toml:

[dependencies]
godot-bevy = "0.12"  # Latest with opt-in plugin system
bevy = { version = "0.19", default-features = false }
godot = "0.5"

The detail worth noticing is default-features = false on bevy. Since version 0.8 the library pulls in only the parts of Bevy it needs, and the default feature set of Bevy would otherwise bring in rendering, windowing and asset systems that Godot already provides and that would fight with it. The comment on the godot-bevy line points at the same thing, noting it is the latest with opt-in plugin system.

The godot dependency at 0.5 is the Godot-Rust binding layer, the official Rust bindings to the engine, and godot-bevy is built on top of it.

The minimum supported Rust version is 1.88.0, and the project explains what that means: the MSRV is the minimum Rust version that can be used to compile each crate. The badge in the documentation header states the same requirement, so a project on an older toolchain has to upgrade before it can depend on this at all.

The Cargo.toml at the root of the repository is a workspace with a dozen members, which shows the shape of the project: the library itself in godot-bevy, a macros crate, a test crate and a test-macros crate, a book-tests member that runs the documentation examples, an xtask crate, an itest crate, and one member per example project, with the examples' Rust halves living beside their Godot scenes.

The opt-in plugin system and what it buys you

Since version 0.8 the library uses an opt-in plugin system, described as being for maximum efficiency. The change is visible in how a project is set up.

The minimal configuration registers your systems and nothing else, with the scene tree and assets included by default:

// Minimal setup - only core features
#[bevy_app]
fn build_app(app: &mut App) {
    // Scene tree and assets included by default
    app.add_systems(Update, my_systems);
}

The fuller configuration adds features one plugin at a time:

// Add specific features as needed
#[bevy_app]
fn build_app(app: &mut App) {
    app.add_plugins(GodotTransformSyncPlugin::default())  // Transform sync
        .add_plugins(GodotAudioPlugin)                    // Audio system
        .add_plugins(BevyInputBridgePlugin);              // Input handling
}

And there is still the everything-at-once option, the GodotDefaultPlugins bundle, which the documentation describes as like v0.7.x, so projects migrating from the older all-in-one setup have a familiar path.

The stated benefits are smaller binaries, better performance and clearer dependencies. That is a real trade in a Rust and Godot project, where the static linking of a large framework into a native extension is exactly the kind of thing that bloats a shipped game.

The plugin names map onto the Godot side of the bridge. GodotTransformSyncPlugin keeps Godot node transforms and Bevy Transform components in step, GodotAudioPlugin covers the audio system, and BevyInputBridgePlugin handles input. The Transform component is the one to understand first, because it is a Godot-Bevy provided component that matches all Node2Ds in the scene, and the whole point of the library is that your Bevy systems can operate on Godot nodes.

Writing a system that moves Godot nodes

The basic example in the documentation shows a system that moves every Node2D to the right, and the code is short enough to read as the model for everything else.

fn position_system(mut transform: Query<&mut Transform>) {
    // For single matches, you can use `single_mut()` instead:
    // `if let Ok(mut transform) = transform.single_mut() {`
    for mut transform in transform.iter_mut() {
        // Move the node to the right.
        transform.translation.x += 1.0;
    }
}

A system is a normal Rust function, and the transform parameter is a Bevy Query that matches all Transform components, with Transform being a Godot-Bevy provided component that matches all Node2Ds in the scene.

The application entry point is marked with the bevy_app attribute and takes the App, and the systems are added to a schedule with add_systems(Update, position_system). Printing to the Godot console uses the godot_print! macro, so a log line ends up in Godot's own output rather than in stdout.

The comment about single_mut is a performance hint rather than a style note. If a system expects exactly one matching node, single_mut returns a Result, so you can handle the case where the count is wrong instead of iterating over it.

For the conceptual background on components, systems and queries, the documentation points at the Bevy quick start, and for the Transform component itself it links to the godot-bevy API page. So the shape of the code is: Bevy queries over a component that stands in for a Godot node, with a plugin bridging the two worlds.

The version compatibility matrix is the thing to check first

Because this library sits between two fast moving projects and one of them is the engine, the version matrix is the most practical piece of documentation in the repository.

| `godot-bevy` | Bevy | Godot-Rust | Godot | |--------------|------|------------|-------| | 0.12.x | 0.19 | 0.5 | 4.6.x | | 0.11.x | 0.18 | 0.4 | 4.6.x | | 0.10.x | 0.17 | 0.4 | 4.5.x | | 0.9.2 | 0.16 | 0.4 | 4.5.x | | 0.9.x | 0.16 | 0.3 | 4.4.x | | 0.8.x | 0.16 | 0.3 | 4.4.x | | 0.7.x | 0.16 | 0.3 | 4.4.x |

Four columns, three of them pinned for you, and the current line is godot-bevy 0.12.x with Bevy 0.19, Godot-Rust 0.5 and Godot 4.6.x.

This is the practical constraint on the whole library. A team on Bevy 0.17 needs godot-bevy 0.10.x, and a team on Godot 4.4 is limited to the 0.7 to 0.9 lines. The library is not usable across Godot versions, and the Godot column is the one you cannot move yourself, because Godot is the engine you are building the game in.

The release history matches the matrix. v0.10.0 came on 2025-12-20, v0.11.0 on 2026-03-08 and v0.12.0 on 2026-09-12, with the last push on 2026-09-16, so the current line is roughly a month old and the repository is not archived.

The origins are also stated. The library was inspired by and originally built upon the work of bevy_godot, which provided similar functionality for Godot 3, and godot-bevy extends the concept to support Godot 4 and Bevy 0.16, and has since diverged quite a bit.

The examples and the development environment

The examples directory is where the features are demonstrated rather than described, and there are three named in the documentation plus more in the tree.

The 2D Platformer is a physics-based platformer, Dodge the Creeps is a classic arcade game, and Simple Movement is the basic transform usage. The tree also holds plugin-test, perf-test, two-way-sync-demo and a run_godot.rs file, and the Cargo.toml has a workspace member for the Rust half of most of those example projects, with a separate itest/rust crate for integration tests.

For development, the project recommends devenv.sh on macOS or Linux, optionally with direnv.net, and once they are set up you can leverage devenv shell in the root of the package to set up a development environment that includes all system dependencies, rust, godot and the other developer tools used in the package. The devenv.nix, devenv.lock and devenv.yaml files are in the repository, along with a .envrc for direnv.

The documentation is honest about the catch, and it is a real one: you can skip all of this and use system-installed tooling of your own, but you should keep in mind that your system dependency versions, like Godot, may drift from what other contributors or the CI tooling use. Since the library version is tied to a specific Godot version in the matrix, a drifting local Godot is a plausible source of confusing failures.

There is a book-tests workspace member, which suggests the examples in the book are executed rather than only compiled, and the CI workflow badge in the documentation header shows the test status is tracked on every push.

Where godot-bevy is the wrong choice

The first limit is obvious but worth stating: this is a Godot binding, not a port. If the goal is to write a game in Bevy without an engine, or to have one Rust codebase that runs on several engines, godot-bevy is the wrong project, because its whole value is the Godot-Rust bridge and the Godot Transform component matching Node2Ds.

The second is the version matrix as an operational fact. Every upgrade of Bevy, Godot-Rust or Godot is a coupled decision, and a team that upgrades Godot for unrelated reasons can find itself waiting for a new godot-bevy line, or pinned to an older Bevy because of it. The library is a moving part between two moving parts.

The third is the scale of the bridging work. Bevy's model and Godot's model do not line up one to one, and the library handles the difference by giving you a component that stands in for a Godot node rather than by making Godot nodes first class ECS entities. That is a sensible design, but it means the boundary between the two worlds is a real design decision in your game architecture, and you will be making it in your systems rather than in the library.

The fourth is the maturity signal. The latest release is v0.12.0, and the project has a Discord as its support channel.

Compare that with using Godot's own GDExtension or C# support, which keeps everything in one language and one API, or with using Bevy alone, where there is no second engine to bridge. The difference in approach is that godot-bevy deliberately takes on the cost of a foreign function boundary and a compatibility matrix, and it pays off only if the value of Godot's editor and rendering outweighs that cost for your team.

Licence, tooling and what to verify before you commit

godot-bevy is distributed under the terms of both the MIT license and the Apache License, Version 2.0, with the details in the LICENSE-APACHE and LICENSE-MIT files, and the manifest records the licence as MIT OR Apache-2.0. Opening a pull request is assumed to signal agreement with these licensing terms, which is a short and clear statement for a project that a commercial game studio might embed. Read the two files yourself for the exact terms.

The Rust side of the repository shows the seriousness of the engineering. The workspace uses edition 2024, resolver 2, and defines extra profiles beyond the defaults: a profiling profile that inherits release with debug info and no stripping, a coverage profile that inherits dev with debug info and incremental disabled, and a package-wide override that sets opt-level 3 for all dependencies in debug builds, with the comment that this optimizes dependencies in debug builds for faster iteration. There is a rust-toolchain.toml, a rustfmt.toml, an xtask crate for automation, and a.cargo/ directory.

Interestingly there is also a Python side, which is not obvious from a Rust project. The pyproject.toml describes a project named godot-bevy whose description is dependencies for use by Python scripts, and says to use the uv command to launch a script using this environment, with Python 3.13 or newer, and it depends on dacite and jinja2, with black as a dev dependency. That is consistent with a project that generates and tests its own examples, and the book-tests workspace member is a workspace member in Cargo terms, so the book examples are part of the same build.

What to verify before committing a project to this is short. Match your Godot version, your Bevy version and the Godot-Rust version against the compatibility table, since only the current line supports Godot 4.6.x with Bevy 0.19. Read the book, because the README deliberately points there for the architecture rather than describing it. Then build the plugin-test and two-way-sync-demo examples, which are the ones that exercise the parts of the bridge most likely to surprise you, and confirm the transform sync behaves the way your game design assumes before you write systems on top of it.

Editorial conclusion

godot-bevy fits a team that has decided to keep Godot's editor and rendering while writing gameplay systems in Bevy's ECS, and who can live with a version matrix that ties the library to a specific Bevy, Godot-Rust and Godot combination. It does not fit a team that wants an engine agnostic Rust game stack, since it is explicitly a Godot binding, and it does not fit a project pinned to an older Godot or Bevy without checking the matrix. Before you adopt it, match your Godot and Bevy versions against the compatibility table, start from the plugin-test or two-way-sync-demo example rather than the empty project, and read the book, since the README points there for the architecture rather than describing it.

Frequently asked questions

Official sources

1. bytemeadow/godot-bevy on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases