Zero-SDK architecture
Zero-SDK architecture is a game server hosting approach where no SDK, plugin, or library is required inside the game server binary. The hosting platform manages the server entirely from the outside — starting, stopping, monitoring, and scaling containers without any code running inside them.
How it works
Your game server is a standard Linux binary packaged in a Docker container. It starts, listens on a port, and accepts player connections. That’s it. The orchestration platform handles everything else: placement, networking, DDoS protection, scaling, failover, and teardown. No callbacks, no heartbeat SDK, no lifecycle hooks in your server code.
Why it matters
SDK-based platforms (AWS GameLift, Agones) require you to integrate their library into your game server. This means:
- Engine coupling — The SDK must be compatible with your engine version. Engine upgrades can break the integration.
- Build complexity — The SDK adds a dependency to your server build pipeline.
- Vendor lock-in — Your server binary depends on platform-specific code. Switching providers means ripping out the SDK and integrating a new one.
- Testing overhead — You need the platform running locally (or mocked) to test your server.
With zero-SDK architecture, your server binary is portable. It runs the same way on your dev machine, in CI, and in production. The integration point is your matchmaker backend (which calls the hosting API), not your game server.
Trade-offs
Zero-SDK platforms have less visibility into what’s happening inside the container. They can’t track player join/leave events, session state, or game-specific metrics unless the game server reports them through a separate channel (e.g. a webhook or log stream). SDK-based platforms get this data for free through the integrated library.