GodotFirebase is a Firebase SDK written entirely in GDScript

What the package actually is, and what it is not

The project describes itself as a Google Firebase SDK written in GDScript for use in Godot Engine projects, and the repository description is implementations of Firebase for Godot using GDScript. That single sentence carries a lot of information. It is not an official Google library, and it is not a wrapper around the official Firebase client SDKs for other platforms. It is a reimplementation, in the scripting language of the game engine, of the service protocols. The subject list makes the coverage concrete: firebase, firebase-auth, firebase-database, firebase-firestore, firebase-realtime-database, firebase-storage and firebase-functions all appear, alongside gdscript, godot and hacktoberfest. The two creators named in the credits are given their areas, with Kyle Szklenski credited as the original creator for Authentication, Database, Firestore, Functions and Storage, and Chuck Lindblom credited for several features across the board. So the scope is the whole service family rather than one narrow corner of it.

The addons directory is how the SDK enters a Godot project

The repository layout is small and tells you the delivery mechanism. The top level holds a .github directory, a .gitignore, a .gitattributes, a CODE_OF_CONDUCT.md, the LICENSE, the README, an icon.png, and two directories that matter: addons/ and ios_plugins/. The addons directory is the Godot convention for a plugin that gets copied into a project, which is how you would install this into your own game. The ios_plugins directory is the one worth pausing on, because it shows where the platform boundary sits. Most of the SDK is pure GDScript and needs no native code, but iOS is a special case, because Apple platforms restrict what a scripting language can reach without a native bridge. The presence of that directory is a fair hint that the split between the pure script implementation and the parts that need platform integration is not perfectly even. The README does not describe how those pieces are wired, so anyone targeting iOS specifically should treat that as something to verify in the code and in the wiki rather than something the documentation settles.

The branch split catches out people who cloned before

The very first thing in the README is a warning in capitals, and it is a good indicator of how the project has evolved. It says that if you downloaded the repository manually before, you will need to update your repo, and it recommends blowing it away and redownloading, while noting that 4.x is the new main branch and 3.x is now its own separate branch. It then offers the git commands to migrate in place instead, renaming the local branch and repointing it at the remote:

git branch -m 4.x main

git remote set-head origin -a

The second half of that migration also involves fetching the origin and setting the upstream of main to origin/main, which is the point where a plugin that people vendored into their project as a plain directory causes trouble. A Godot addon is often committed into the game repository, which means two copies of the SDK and a merge conflict waiting to happen. The tag names tell the same story from the other direction. The releases are named godotfirebase-v6.0.6, godotfirebase-v6.0.5 and godotfirebase-v6.0.4, so the plugin has moved well past the 4.x line the note describes, and the note is now history rather than current instruction. Nobody cloning fresh today will hit it, but everybody with an old copy has already hit it.

Cloning is the entire documented installation step

There is no package manager entry and no editor plugin marketplace listing in the documentation. The cloning section offers an SSH form and an HTTPS form of the same command, so the choice is only about which remote you trust with your credentials:

git clone [email protected]:GodotNuts/GodotFirebase.git

git clone https://github.com/GodotNuts/GodotFirebase.git

After that, the README deliberately stops. The How to Use section says the best place to find any and all questions on how to install, activate, and use this plugin is through the wiki, and links to the project wiki. The wording, any and all, suggests the documentation burden is real. A wiki maintained outside the repository is also a documentation that can drift from the code without a pull request to catch it, and the project does not publish a rendered API reference in the tree. The only in-repository pointers to usage are the issue guidelines for reporting problems and the contributing guidelines for changes, both in the wiki as well, with the repository holding only the plugin code and its licence. Contributors are told to feel free to fork the repo and follow those guidelines.

Version 6 is where the project is now, and the dates are uneven

The release history is short but tells you something about the rhythm. godotfirebase-v6.0.6 was published on 2026-05-27, godotfirebase-v6.0.5 on 2025-04-25, and godotfirebase-v6.0.4 on 2024-10-19. Those three dates span about a year and a half with three releases, and the gap between the first two is more than a year. A patch release in the 6.0 line means the public API was held stable across it, which is what you want from a plugin whose consumers commit it into their game repository, since every API change lands in somebody else's merge. The repository itself is not archived, and the last push was on 2026-09-13, so the code is being touched. The licence is MIT, held in the LICENSE file at the top of the tree, which is the permissive choice and means you can vendor the addon into a commercial game without owing anything back beyond keeping the notice. The hacktoberfest topic tags and the hacktoberfest2022 tag tell you the project has taken contributions through that route at least once, which is consistent with a community-maintained plugin rather than a product with a team behind it.

Where GodotFirebase is the wrong tool

Three cases argue against it. The first is a project with a strong reason to use the official SDKs. If you need behaviour that tracks a Google release precisely, a service the reimplementation has not covered, or an authentication flow with device specific requirements, then the official Firebase client libraries are the reference and this is a parallel implementation that will lag. The second is a team that needs support. A community plugin with two named creators, a Discord link and a wiki is fine for a hobby project and a problem for a studio with a release date, because when the reimplementation of a proprietary service protocol breaks after a backend change, there is no vendor to escalate to and no compatibility promise from Google. The third is a project that already has a native extension layer, because you would then be maintaining two Firebase clients in one project. The alternative to consider is not another addon but the shape of the design. A Godot game that only needs a leaderboard, a save file or a small user profile can talk to the realtime database over plain HTTP from GDScript, and a game that needs push, or sign in with Apple, or analytics is at that point past what a script layer can reasonably cover. In that case the honest answer is to split the backend work into a service you own and keep the game talking to that.

Editorial conclusion

Adopt GodotFirebase when your Godot project needs Firebase and you would rather stay in GDScript than maintain a native extension, and check the wiki before you commit because installation, activation and usage are documented there rather than in the repository. Verify first which branch line you are on, since the README warns that 4.x became the main branch with 3.x split off, and confirm the addons/ path is where the plugin lives in your Godot version before assuming the copy step works.

Frequently asked questions

Official sources

1. GodotNuts/GodotFirebase on GitHub
2. Issues
3. License: MIT
4. README
5. Releases