GodotHub: a Tauri desktop hub for Godot projects, versions and Git
What if Unity Hub and GitHub Desktop had a Baby but its Adopted? Yeah..
At a glance
- What is it?
- GodotHub is a Tauri and React desktop app that puts Godot project management, engine version downloads, templates and Git operations in one window. It is a young, fast-moving tool, and the README is honest about what it does not cover.
- Who is it for?
- Adopt GodotHub if you keep several Godot projects on one machine and want version pinning plus Git operations without leaving the project list. Skip it if you only run one project, or if your team standardises on the official Godot launcher's project list and expects it to stay authoritative.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 19, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What GodotHub is for, and who actually needs it
Godot's own launcher keeps a project list, but it does not manage engine builds, templates or Git. GodotHub fills that gap as a desktop application: it tracks projects, downloads and pins Godot versions, stores reusable templates, and exposes Git status, staging, commits and branches in the same window. The repository describes it as an adopted child of Unity Hub and GitHub Desktop, which is a fair summary of the feature set.
The audience is people with more than one Godot project. If you juggle a game jam entry, a client prototype and a long-running project, each expecting a different engine version, the version registry and the version warnings earn their place. If you have a single project on one engine build, the tool adds a second place to look without removing the first.
How the pieces fit: projects, versions, templates, workspaces
Projects are the central object. According to the README, tags are read straight from `project.godot` and stay in sync with the Godot launcher, so the app treats the project file as the source of truth rather than maintaining a parallel metadata store. Projects can be created, imported from disk, or cloned from a Git repository. Batch operations let you select several at once and change versions, assign categories, toggle pins or remove them from the library.
Versions are downloaded from GitHub releases and filtered for the current platform, with progress tracking, resume support and concurrent downloads configurable up to 10 at once. Pinning a version as current makes GodotHub drop a `Godot` launcher into its aliases folder, so scripts, test runners and MCP servers get a stable path that follows the pin. Extra aliases such as `godot-mono` or `godot-next` can be attached to specific versions. The README states that deleting a launcher from the folder removes the alias from the app too, which means the filesystem and the UI are kept in step in both directions.
Templates are ordinary project directories saved for reuse, with a preview of the full directory tree and a file watcher on the template directory, so editing a template folder updates the library. Workspaces sit above all of this as separate scopes with their own icon and colour. That is a reasonable hierarchy, though it means a project belongs to exactly one workspace, and the README does not describe moving or sharing one between workspaces.
Installing GodotHub and pinning your first engine version
The README points to the project homepage at https://ryko.is-a.dev/godothub and to the GitHub releases page rather than documenting a package-manager install. Releases are tagged (v1.4.3 is the most recent listed), and the repository is a Tauri app, so the build path runs through the Tauri CLI.
If you build from source, the package scripts are the entry point. This installs dependencies and starts the Vite dev server with the Tauri shell:
bun install
bun run tauri devFor a distributable build, the script also patches the AppImage for Wayland:
bun run tauri:buildThe README does not state which platforms have prebuilt installers on the releases page, so check that page for your system before assuming a binary exists. Windows users should note the WebView2 requirement that Tauri apps carry; the README does not spell it out.
After launching, the first real task is registering an engine build. Open the Versions view, browse the GitHub release list filtered for your platform, and download one. Then pin it as current. GodotHub writes a `Godot` launcher into its aliases folder, and that path is what your scripts should call. The practical check is to run that launcher from a terminal and confirm it starts the version you pinned; if it does not, the alias folder is the first place to look.
The Git panel is a convenience layer, not a second GitHub Desktop
The Git integration covers status overview, stage and unstage, commit with optional amend, push, pull, fetch, branch listing and switching, stash push and apply, an inline diff viewer, discard changes, repository init, remote management, and undo for the last commit or a pull. Status polls every 30 seconds.
That is a broad surface, and the polling interval is the detail worth pausing on. Thirty seconds means the panel can be stale while you work in another terminal, and a tool that shows uncommitted changes it has not yet noticed is worse than one that shows nothing. The README does not document a manual refresh control or a way to change the interval.
The undo features are the other place to be careful. Undoing the last commit and undoing a pull are both described, but the README does not document what undo does to the working tree, whether a pull undo is a hard reset, or how conflicts during a pull are surfaced. If your team's workflow depends on rebases, submodules, worktrees or signed commits, the README is silent on all of them, and you should assume the panel will not cover your case.
Where GodotHub gets in the way
The version registry removes entries whose executables have gone missing, which is helpful until you move an engine install and the app quietly prunes it. Re-importing is the fix, and the README documents importing from any folder or dragging a `.zip`, but nothing warns you before the prune.
Templates are copied into new projects, so a template that drifts from the projects built on it stays drifted. The file watcher keeps the library in sync with the template directory, not with the projects that already exist.
The bigger limitation is scope. GodotHub is a desktop GUI for one developer's machine. There is no documented team sync, no shared project registry, no CI integration, and no headless mode. If your build pipeline needs to install a Godot version on a CI runner, this app is not the tool for that job; the alias folder it manages is local. And if you already drive Godot from the command line and Git from a terminal, the app duplicates workflows you have automated rather than replacing them.
How it compares with the official Godot launcher
The official launcher ships with Godot and manages a project list and engine versions. GodotHub overlaps on both, then adds templates, workspaces, categories, drag-and-drop ordering, project property breakdowns and a Git panel.
The difference in approach matters more than the feature count. The official launcher is the reference implementation: whatever it writes into `project.godot` is what Godot itself expects, and its project list is the canonical one for the editor. GodotHub reads tags from `project.godot` and keeps them in sync, which suggests it treats the launcher as authoritative rather than competing with it. But the app also maintains its own library, its own aliases folder and its own pinned version. Those are extra state, and extra state can disagree with the launcher.
If you want one tool that the engine vendor maintains, use the official launcher. If you want Git operations and template management next to the project list, GodotHub is the one that has them.
Maintenance, licence and what an upgrade costs you
The repository is not archived, and the last push was on 2026-09-15. Releases have been frequent: v1.4.1 on 2026-09-04, v1.4.2 on 2026-09-09, v1.4.3 on 2026-09-13. The package.json version is 1.4.4, ahead of the latest listed release, which suggests development continues between tags.
That cadence is the upgrade cost. A tool that ships a release most weeks will change its UI and its internal registry format, and the README does not document a migration path or a compatibility guarantee between versions. Back up your aliases folder and your project library before a major upgrade, or at least know where GodotHub stores them.
The licence is MIT. That permits commercial use and modification, and it means the project comes with no warranty. The README does not describe any commercial support offering, and the Patreon link is a funding channel rather than a support contract. If your organisation needs a support agreement, nothing in the repository provides one.
Editorial conclusion
Adopt GodotHub if you keep several Godot projects on one machine and want version pinning plus Git operations without leaving the project list. Skip it if you only run one project, or if your team standardises on the official Godot launcher's project list and expects it to stay authoritative. Before installing, check the releases page for your platform, confirm the Windows WebView2 requirement, and read docs/ to see whether the Git panel is documented as a full remote-workflow replacement or a convenience layer.
Frequently asked questions
Is Godot still good in 2026?
That question is about the engine, not about GodotHub. The repository does not make claims about Godot's standing; it targets Godot projects and downloads official Godot builds from GitHub.
What is Godot used for?
GodotHub's own material does not describe Godot's use cases. What it does show is that Godot projects are directories containing a `project.godot` file, and that engine builds are distributed as releases on GitHub.
Can you make AAA games in Godot?
The repository does not address game scale or production budgets. Its project properties panel breaks a project down by file type (scripts, scenes, images, audio, 3D models) with sizes and counts, which is as far as the documentation goes.
Community notes