Short, honest answers. If your question isn't here, use the feedback form on the landing page — it goes straight to the developers.

What does SpawnWeaver cost?

Nothing right now. SpawnWeaver is in alpha and free while we stabilize it. When paid tiers arrive, there will be a free tier that comfortably covers development and small playtests, and alpha users will get generous notice before anything changes.

Which engines are supported?

Godot 4.3+ only, via the GDScript SDK. There is no Unity/Unreal/web SDK. The wire protocol is documented JSON over a WebSocket, so a client for another engine is possible to write — but Godot is the product.

How many players can it handle?

Honest alpha numbers: a single server comfortably handles hundreds of concurrent connections and thousands of messages per second. Rooms support up to 64-player matchmaking sizes, but the sweet spot is small-room games (2–16 players). SpawnWeaver runs on one node today — there is no multi-node clustering yet. It is good enough for playtests and small launches, not for a viral hit on day one.

Does my game need the secret key?

Never. Game clients only use the public key (pk_…), which is safe to ship and commit. The secret key (sk_…) is for your own servers and tools (HTTP storage access, admin scripts). If you ever put sk_… in a client build, regenerate it from the dashboard.

Can I run server-side game logic or dedicated servers?

Not yet. SpawnWeaver relays events and hosts shared state between clients; it does not run your game code. The usual pattern is host-authoritative: the room's host client makes the decisions and writes room state (see Best practices). Dedicated/authoritative simulation is not part of the current release.

Which export platforms work?

Desktop exports (Windows, macOS, Linux) work out of the box — the SDK is pure GDScript over WebSockets. Mobile exports should work like desktop but see less testing today.

Web (HTML5) exports work — verified end to end (a browser build connects, joins rooms, and syncs state like any desktop build). The SDK authenticates via the connect URL (never custom headers, which browsers can't set on WebSockets), uses WebSocketPeer (browser-WebSocket-backed on web), needs no threads, and stores identity in user:// (IndexedDB-backed on web). The plugin also ships your spawnweaver.cfg inside every export automatically — no export-filter fiddling. Two caveats: a page served over https:// must connect via wss:// (the default — mixed content is blocked otherwise), and two tabs of your game in the same browser share one player identity.

Where is my data stored?

Player storage lives in the service's PostgreSQL database on infrastructure we operate; realtime room data exists only in memory and is never persisted. Storage entries are yours — delete them any time via the SDK or the dashboard, and deleting a project removes its data.

What happens when the server restarts?

Active rooms and sessions are dropped — realtime state is in-memory. Clients reconnect automatically and player identities survive, but everyone is back in the menu and needs to create/join rooms again. Player storage is unaffected — it's in the database. Restarts are rare and scheduled where possible.

Can my AI assistant help me build with SpawnWeaver?

Yes — point it at /llms.txt (a compact index) or /llms-full.txt (the entire documentation as one markdown file). Paste the full file into Claude, ChatGPT, or Copilot Chat and it can answer questions and write SpawnWeaver code against the real, current API. The AI tutorial prompts in the Learn section pair well with this.

Is SpawnWeaver open source?

The SDK is source-visible by nature — it's plain GDScript that lives in your project under addons/spawnweaver/, so you can read, step through, and patch every line your game runs. The backend is a hosted service, not open source — you never deploy or operate anything. License terms for the SDK are still being finalized during the alpha.

How does player identity work without accounts?

The first connect creates an anonymous player id and a signed token; the SDK stores the token on the player's machine and presents it on every reconnect. Same machine, same player — no sign-up, no passwords. Details in Players & identity.

How is this different from Photon?

Photon is a mature, engine-agnostic commercial platform with big-scale infrastructure. SpawnWeaver is Godot-native and radically simpler: one autoload, awaitable calls, two drop-in nodes, and a debugger that speaks Godot. If you want a 4-player co-op or a small arena game running this afternoon without learning a networking framework, that's the trade we optimize for. Migrating? See Migration.

How is this different from Nakama?

Nakama is an open-source game server you deploy and extend with server-side Lua/Go/TS modules — powerful, and correspondingly more to operate and learn. SpawnWeaver is a hosted service with no server code to write: rooms, matchmaking, state sync, and storage over one WebSocket. If you need custom server-side logic today, Nakama is the better fit; if you need multiplayer without backend work, SpawnWeaver is.

Why is my room gone after everyone left?

Rooms with no connected members expire after about a minute (the empty-room TTL). Rooms are meeting places, not persistent worlds — persist anything long-lived in player storage and recreate rooms on demand.

Can two players on the same machine test my game?

Yes — click Playtest ×2 in the SpawnWeaver dock (or use Godot's Debug → Run Multiple Instances → 2 and press Play); each window is a separate client. This is the standard local test loop (see the Quickstart).