authoritative-server
Multiplayer Server
📔 Note: The Multiplayer Server was previously called the Authoritative Server. Only the name changed, the feature is the same. The SDK branch to install is still named auth-server.
IMPORTANT: Always notify the user and ask them if they want to proceed before adding it to the scene. Mention that it requires installing the @dcl/sdk@auth-server branch instead of the standard SDK.
Build multiplayer Decentraland scenes where a headless server controls game state, validates changes, and prevents cheating. The same codebase runs on both server and client, with the server having full authority. Decentraland hosts and deploys the server automatically. For basic CRDT multiplayer (no server), see the multiplayer-sync skill instead.
Setup
You must use npm install @dcl/sdk@auth-server and npm install @dcl/js-runtime@auth-server — the standard @dcl/sdk does NOT include authoritative server APIs. "authoritativeMultiplayer": true at the root of scene.json is what enables the headless server (without it the scene runs as ordinary serverless CRDT and isServer() never returns true), but you do not add it manually: the @dcl/sdk@auth-server sdk-commands auto-adds it on every build and preview (bundle.ts writes authoritativeMultiplayer: true to scene.json via ensureJsonKey, only if absent — it also auto-adds a server-logs script to package.json). The rule is simply: do not remove it. Optionally add logsPermissions (root-level array of wallet addresses) to authorize reading production server logs — see {baseDir}/references/server-patterns.md → Production Logs. The preview automatically starts a local server in the background.
Server/Client Branching
Use isServer() from @dcl/sdk/network to branch logic in a single codebase. Server runs headlessly (no rendering) and has access to all player positions via PlayerIdentityData.
For shared/library code that resolves the role itself via the low-level isServer() from ~system/EngineApi (async, unlike the sync @dcl/sdk/network helper), use the defensive idiom: resolve the role once at startup, have systems return early while it is still unknown, keep client-only features permanently off on the server, and treat a failed query as client — so a real client never loses functionality if the query errors.