Bevy: A Rust Game Engine That Ships Breaking Changes Every Three Months

What Bevy solves, and the developers it is built for

Bevy targets a specific kind of developer: someone writing a game or simulation in Rust who wants the engine to be a library of composable crates rather than a monolithic application with a scene editor at the centre. The README describes it as "a refreshingly simple data-driven game engine built in Rust," and the design goals list five commitments: capable, simple, data focused, modular, and fast. The modular goal is the operational one. Bevy is published as a workspace of crates under crates/, and the Cargo features documented in docs/cargo_features.md let you compile only the parts you use. If you are building a 2D game and do not want the 3D renderer in your dependency graph, that is a configuration question, not a fork.

The data-focused goal is the second half of the pitch. Bevy is built on the Entity Component System paradigm, where game state lives in components attached to entities and behaviour lives in systems that query those components. That is an architectural commitment, not a stylistic one. It shapes how you write every frame of logic, and it is why the engine appeals to developers who already think in terms of data layout and parallel execution rather than object hierarchies.

The audience is narrower than a general game engine's. The README carries a warning block in capitals that says Bevy is "still in the early stages of development," that important features are missing, and that documentation is sparse. A new version with breaking API changes arrives roughly once every three months. That warning is the most useful sentence in the repository for anyone deciding whether to adopt it.

The ECS mechanism and how a Bevy app is assembled

A Bevy program is an App. You create one, add plugins, and run it. Plugins are the unit of composition: DefaultPlugins is the bundle that brings up the standard window, renderer, input and asset machinery, and you can add your own alongside it or replace parts of it. The README gives the minimal window example directly:

use bevy::prelude::*;

fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .run();
}

That is the whole program. Systems are functions registered on a schedule, and the engine decides when they run and whether they can run in parallel based on which components they read and write. This is where the data-driven design pays off: the scheduler derives parallel execution from the access patterns you declare, so you do not hand-write threading.

The repository layout reflects the same modularity. Engine code lives in crates/, runnable examples are organised by topic under examples/ with directories for 2d, 3d, animation, asset, audio, camera, ecs, gizmos, gltf, input, picking, reflection and more. The Cargo.toml workspace also includes examples/mobile, examples/no_std/* and examples/reflection/auto_register_static, which tells you the project treats mobile, no_std and platforms without inventory support as supported targets with their own example crates rather than afterthoughts. If you want to know whether a feature exists, browsing examples/ is more reliable than reading prose documentation, because the examples are compiled as part of the workspace.

Installing Bevy and running your first example

Bevy is distributed on crates.io as the bevy crate, so the normal path is adding it to a Cargo project. The README points to the official Quick Start Guide and the Setup guide for environment preparation, and notes that the MSRV is generally close to the latest stable Rust release. The workspace Cargo.toml pins rust-version = "1.96.0" for the development version, so check that against your toolchain before you start.

To try the engine without writing code, the README gives a two-command path: clone the repository, check out the release branch, and run an example. The breakout example is the one it names.

# Switch to the correct version (latest release, default is main development branch)
git checkout latest
# Runs the "breakout" example
cargo run --example breakout

You should see a window open with a playable Breakout game. Note the comment in that snippet: the default branch is main, which is the development branch, so checking out latest is what puts you on released code rather than work in progress. Skipping that step means you are building 0.20.0-dev, which is what the workspace Cargo.toml declares.

For your own project, the README states that Bevy builds fine with default configuration on stable Rust, but recommends enabling the "fast compiles" setup from the Setup guide for iterative work. That setup is a documented configuration change, not a default, and it is worth doing before your first long build rather than after.

The breaking-change cadence is the real adoption cost

The README is unusually direct about this: a new version containing breaking API changes is released approximately once every three months, migration guides are provided, and the project cannot guarantee migrations will always be easy. The release history matches that description. v0.19.0 landed on 2026-06-18 and v0.19.1 on 2026-08-13, with release candidates in between, and the development tree is already at 0.20.0-dev.

For a hobby project this is manageable. For a commercial title with a long tail, it is a recurring engineering cost that has to be budgeted, not discovered. The mitigation the project offers is the migration guides under bevy.org/learn/migration-guides/, plus the release-content directory in the repository. That is more than many young projects provide, but a guide is not the same as a compatibility layer. There is no long-term support branch described in the README.

The second limitation is documentation coverage. The README says documentation is sparse, and the docs section points to three places: the Quick Start Guide, the API docs generated from doc comments, and the official examples. When the prose runs out, the examples and the source are what remain. That is workable for an engineer who reads Rust comfortably, and a real obstacle for someone who expects a complete manual.

Bevy versus Godot: code-first ECS against an editor-first engine

The comparison people reach for is Godot, and the difference is not quality but where the authoring happens. Godot is editor-first: you build scenes in a visual editor, attach scripts, and the engine owns the project format. Bevy is code-first. There is no editor in this repository, and the README's getting-started path runs through Cargo, the Quick Start Guide and the examples. Your game is a Rust program, and your scenes are constructed in code or loaded from asset formats such as glTF, which the examples/gltf directory covers.

That changes who can contribute. A designer cannot open a Bevy project and rearrange a level without touching Rust source. A programmer gets a build system they already understand, dependency management through Cargo, and the ability to unit-test game logic like any other Rust code.

The second difference is the ECS. Godot's node tree is an object hierarchy; Bevy's entities and components are a data layout, and the scheduler parallelises systems based on declared access. If you want the ECS model specifically, that is the reason to pick Bevy. If you want a scene editor and a gentler on-ramp, Godot is the better fit, and no amount of Rust affinity changes that.

Licence terms and what you inherit

Bevy is dual-licensed under MIT or Apache-2.0, at your option, which the README calls the de-facto standard in the Rust ecosystem. For most users this is the permissive end of the spectrum and imposes no source-disclosure obligation on your game. The repository carries both LICENSE-MIT and LICENSE-APACHE, and the Cargo.toml license field reads "MIT OR Apache-2.0".

The caveat is that not all code in the repository is under those terms. The README states that some engine code carries additional copyright notices and licence terms due to external origins, generally BSD-like but varying by crate. Where a crate's README has a License header, those terms are listed there, and the license field of each crate reflects them.

Assets are a separate matter. The assets/ directory used by the examples falls under different open licences, and the README notes those assets are not distributed in the published bevy crates and will not be in your game unless you copy them in yourself. CREDITS.md holds the per-file details. If you vendor example assets into a shipped product, that file is the one to read. This is a description of what the repository states, not legal advice; if your situation is unusual, a lawyer is the right person to ask.

Editorial conclusion

Bevy suits Rust developers who want an ECS-first engine, are comfortable reading source and examples, and can absorb a breaking release roughly every three months; the v0.19.1 release on 2026-08-13 and the 0.20.0-dev version in Cargo.toml show that cadence. It is the wrong choice if you need a general-purpose visual editor or cannot schedule migration work, because the README states that important features are missing and documentation is sparse. Before committing, verify the MSRV against your toolchain, check that the cargo features you need are documented in docs/cargo_features.md, and read the migration guides for the releases between your current version and the one you plan to use.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes