Security: where your project lives and what leaves your machine

Flockbay is a desktop application for Windows. It is downloaded and installed, and it is not a browser tool with your project on a server somewhere. When you make a project, the project is a folder on your disk.

That folder is a Godot project. Godot is open source and the app ships with a copy of it inside, which is what runs your game when you press play. There is no streaming, no remote rendering and no build queue, so playing your own game involves nothing outside your machine.

A lot of security questions about creative tools are really questions about where the work is stored. Here it is stored where you put it, and you can copy it, back it up or move it to another machine the same way you would any other folder.

Building is online. Flockbay writes your game's code, asset generation produces art, and world data is fetched over the network, so all three need a connection. When you ask Flockbay for something, the request and the context it needs to answer sensibly go to the service and the resulting code comes back.

We say this plainly rather than advertising an offline mode, because there is not one and a tool that pretended otherwise would be lying about something you can check in an afternoon. Building needs the connection. Playing what you already built does not.

The practical implication is worth stating: treat what you describe to Flockbay the way you would treat anything you type into an online service. If a project must never touch a network at any stage, this is not the right tool for it.

Everything Flockbay writes is GDScript, in files, inside your project. You can open them. You do not have to — the whole design assumes you will not — but the option is what makes the claim checkable rather than a promise.

This is also why the project stays portable. Someone who does write code can open the same folder in stock Godot and read every line that runs in your game. Nothing important is hidden in a format only this app understands.

A new install builds on a guest account that our server makes for it, with no email address and no password. Saving that account is a free sign-in in your browser, and the sign-in is kept in your operating system's keychain. Flockbay has no paid plans and asks for no card. An API key you connect stays in your operating system's keychain.

Flockbay is free and covers the whole builder. Flockbay is free on your own AI: your Claude or ChatGPT plan, your own agent, or an API key. Nothing about what the engine itself can do is held back. There is no team or enterprise tier, because this is a desktop app installed on a machine rather than a service seats are bought for.

More on this: You do not sign in to use Flockbay. A new install builds on a guest account.

Flockbay updates itself, which is how fixes reach you rather than sitting in a release note nobody reads. The app checks for a new version and applies it, and the copy of Godot that runs your game comes with the app rather than being installed separately.

Because the game runs locally, the app is doing something a browser tool never does: executing code on your machine. That code is the GDScript in your own project plus the engine, and both are readable — Godot is open source and your project is a folder you own.

The honest summary is that the trust boundary here is narrower than it looks. The network is involved while you build. Everything after that happens on hardware you control, in files you can open.

More on this: What happens if I stop paying?

If you find a problem — in the app, in the website, or in how something is handled — tell us. Flockbay is early software and the useful thing to do with an early report is fix it, not manage it.

The honest position on a young product is that the security story improves with attention, and outside attention is the kind that finds what internal attention misses.