# Godots: a desktop hub for Godot versions and projects

> Godots is a lightweight desktop app for managing Godot Engine installations and projects, built so that it looks and behaves like the Project Manager Godot ships with. Its real additions are multi-version installs, binding a specific engine version to each project, drag and drop of project folders and a command line interface.

**MakovWait/godots** — Ultimate go-to hub for managing your Godot versions and projects!

- Repository: https://github.com/MakovWait/godots
- Stars: 814 · Forks: 65
- Language: GDScript
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/makovwait-godots

## Deliberately built to look like the Project Manager

Godots is a lightweight desktop app for managing your Godot Engine versions and projects. The description of what it does is deliberately narrow: everything you need is in one place, downloading editors, keeping multiple versions and organising your projects, in an interface that looks and feels just like the built-in Godot Project Manager.

That last clause is the design decision that matters. Godots is written in GDScript, the engine's own scripting language, and the repository root contains a project.godot file, a plug.gd addon entry point, an export_presets.cfg and an icon.svg with its import file. It is a Godot application, not a wrapper around one, and it is presented as a replacement for the manager that ships with the engine rather than as a different kind of tool.

The effect is that there is no new mental model to learn. If you have used the Project Manager, the list of projects, the import button and the create-project flow are where you expect them to be. That is a deliberate trade: the app gives up the chance to redesign the workflow and gains the chance to be adopted by people who already know one.

The licence is MIT, the licence file is LICENSE.md, and the project is published under releases on GitHub with version names that follow the Godot convention, v1.4.2.stable being the most recent, tagged on 2026-06-06. The last push to the repository was on the same day, and before that v1.4.1.stable came on 2026-05-07 and v1.4.stable on 2025-10-10.

## Several engine versions, side by side

The first feature group in the documentation is the one that separates Godots from the built-in manager: downloading and managing any Godot version.

You can fetch any official release from GitHub, keep multiple versions side by side, and add custom local Godot binaries that the app did not download. The third point is the one people underestimate. A local binary matters for builds that are not the public release: a patched editor, a self compiled engine, a nightly from your own pipeline. The built-in manager knows only about installed editors it put there itself.

The second feature group is the full project manager: adding, importing, organising and launching projects, and binding specific engine versions to individual projects.

That binding is the feature the whole application exists to make convenient. A project that was made for Godot 4.2 and one made for 4.4 need different editors, and opening the wrong one produces confusing errors that have nothing to do with your code. Godots stores that association per project and then uses it: you launch or edit a project directly with its assigned version, and the app opens the right editor rather than the newest one on the machine.

Import is flexible too. You can drag and drop a project.godot file or an entire project folder, so the classic case of a project that lives outside any organised folder is covered. Once projects are in, you can also open a project directly with its assigned version and edit it from there, rather than launching an editor first and then opening the project inside it. For a studio where different clients are on different engine versions, that per-project binding is the difference between a working setup and a support channel.

## A CLI for the parts you want to script

Godots ships a command line interface, documented separately from the user-facing features, and the documentation points at a CLI section in a separate file under .github/assets, at the anchor for CLI in FEATURES.md.

The separation matters more than it looks. A GUI application that manages a set of editors and projects is exactly the kind of tool you want to drive from a script, because the same state, the list of installed versions and the project to engine mapping, is the state a build script needs to reason about. The documentation describes the CLI as managing projects and versions through the command line, and keeping the reference in its own file rather than in the README suggests it is a substantial surface rather than a token flag.

What the excerpt does not tell you is the command syntax, whether the CLI can install engines or only list and launch them, and whether it shares state with the GUI. Those are the details to check in FEATURES.md before you build anything on it, and they are exactly the details that decide whether the CLI is a scripting interface or just a convenience wrapper.

It is also worth noticing what the CLI sits next to. The same application that fetches engine releases from GitHub could in principle automate environment setup on a build agent, and if the CLI exposes that, the tool stops being a desktop convenience and becomes part of a pipeline. That possibility is worth testing against the documentation rather than assuming.

## Packaging on three platforms, one manual step on macOS

The installation section is per platform, and the differences are mostly about how the binary is distributed rather than about features.

On Windows you download the ZIP, extract it and run the executable, and the documentation says no additional setup is required. On Linux you unzip and launch the binary directly, and there are two community maintained alternatives: a Flathub listing, and for Arch Linux the AUR packages godots-bin and godots-git. The word community maintained appears in brackets for both, which is the project's own way of marking that those channels are not built and published by the author.

On macOS you unzip and run Godots.app, and the documentation warns that macOS may require removing the quarantine flag:

```bash
sudo xattr -r -d com.apple.quarantine /Applications/Godots.app
```

That step is the classic consequence of distributing an app outside the App Store, and it is a real friction point: it needs sudo, it is a system-wide attribute change on the app bundle, and on a managed Mac it may be blocked outright.

All downloads come from the GitHub releases page, and the documentation gives a direct link to the latest releases. There is no package manager of its own, no auto-update mechanism described in the excerpt, and no stated support policy for the community packages, so an installation is a manual act that you repeat when a new version appears.

The repository does contain a packaging directory alongside the project files, which suggests the platform packaging is built from the same tree rather than maintained separately.

## Theming and HiDPI on Godot's own UI stack

Two smaller features are worth a look because they affect day to day comfort more than they sound like they would.

The first is HiDPI and Retina support, which the documentation describes as a sharp, crisp UI on high-resolution displays. Since Godots is itself a Godot application, this is a case where the framework's own rendering settings decide the outcome, and the author has tuned them so the interface is not a blurry scaled version of a low resolution layout.

The second is theming. Godots supports custom themes compatible with Godot's own theming system, and there is a theming documentation file under .github/assets. The word compatible is doing work: a theme is a Godot theme resource, which means it is authored with the engine's own theme system rather than with a separate styling language, and the repository has a theme directory that presumably holds the shipped defaults.

This is where the choice of implementation language pays off. A third party application written in Godot inherits the engine's widget rendering, its font handling, its HiDPI logic and its theme format, and a user who already customises Godot can reuse that knowledge and those assets. The same choice also constrains the app: it can only look like a Godot application, and anything the engine does not offer has to be worked around inside the engine's own model.

The repository also carries an assets directory and an addons directory, which is where a Godot project keeps its plugins, so the structure matches a normal Godot project layout rather than a compiled binary layout.

## Where Godots sits against the built-in manager

The honest comparison is with the Godot Project Manager, because that is the tool it is explicitly modelled on and the one it replaces in practice.

The built-in manager is always present, it is updated with the engine, and it opens the editor you are running. It does not download engine versions for you, it does not keep several versions side by side, and it does not record which version a given project expects.

Godots adds exactly those three things, and then adds the drag and drop import, the per-project version binding and a command line interface on top. In exchange, you accept a separate application that has to be installed and kept current, and you accept that the two managers can disagree about what is installed.

That last point is the practical risk. If you keep using the built-in manager sometimes, or if a colleague opens a project in the editor directly, the version binding that Godots maintains is bypassed, and the benefit quietly disappears. A setup where every project is opened through Godots gets the binding; a mixed setup does not.

The other thing to weigh is the age of the line. The last release, v1.4.2.stable, was tagged on 2026-06-06 and the last push was the same day, so the project is inside the window where it can be described as receiving work, but there is no sign of a release cadence after that date in the tags. For a tool whose whole value is tracking engine versions, a stalled release line is a reason to keep the built-in manager installed.

The repository is a normal Godot project with a src directory, a tests directory and a theme directory, and it is distributed as release artefacts rather than as a package you build yourself, so adoption does not require a Godot toolchain of your own.

## Conclusion

Godots suits a solo developer or a small studio working across several Godot versions, who wants one place to download editors, keep old ones around for old projects and open each project with the engine it expects. It is the wrong choice if you have a single pinned engine version, because the built-in Project Manager already covers that case, and it is the wrong choice if you need CI to install engines automatically, since the project describes downloads and management through its own interface rather than a scriptable installer. Verify three things before you switch: that the version you bind to each project matches what the project expects, that your platform's package is the one you trust, since the Flathub and AUR listings are described as community maintained, and on macOS that the quarantine flag removal is acceptable in your environment.

## FAQ

### What is Godots?

It is a lightweight desktop app for managing Godot Engine versions and projects, written in GDScript and designed to look and feel like the built-in Godot Project Manager. It is MIT licensed.

### How do I install Godots on Linux and macOS?

On Linux you unzip and launch the binary directly, or use the community maintained Flathub listing or the AUR packages godots-bin and godots-git for Arch Linux. On macOS you unzip and run Godots.app, and you may need to remove the quarantine flag with sudo xattr -r -d com.apple.quarantine /Applications/Godots.app. Downloads come from the GitHub releases page.

### Can Godots keep several Godot versions at once?

Yes. You can fetch any official release from GitHub, keep multiple versions side by side, and add custom local Godot binaries that the app did not download itself.

### Can Godots open a project with a specific engine version?

Yes. You can bind specific engine versions to individual projects, and then launch or edit a project directly with its assigned version. Projects can also be added by dragging a project.godot file or a whole project folder into the app.

### Does Godots have a command line interface?

Yes. The CLI manages projects and versions from the command line, and the documentation for it is in the CLI section of the features file under .github/assets. The app also supports custom themes compatible with Godot's own theming system, documented separately, and HiDPI and Retina displays.

## Sources

- [Issues](https://github.com/MakovWait/godots/issues)
- [License: MIT](https://github.com/MakovWait/godots/blob/main/LICENSE)
- [MakovWait/godots on GitHub](https://github.com/MakovWait/godots)
- [README](https://github.com/MakovWait/godots/blob/main/README.md)
- [Releases](https://github.com/MakovWait/godots/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/makovwait-godots