Vendor lock-in
Vendor lock-in is the accumulated cost of leaving a hosting provider — the technical and commercial dependencies that make switching expensive, slow, or risky. In game server hosting it is rarely one thing; it is the sum of how deeply a platform embeds itself in your game code, your infrastructure choices, and your bill.
The forms it takes in game hosting
SDK / code lock-in. When a platform requires its SDK inside your game server binary (the GameLift Server SDK, the Agones SDK), your server carries vendor-specific lifecycle code. Switching means ripping that out and integrating someone else’s — and keeping it compatible across engine upgrades. A zero-SDK server, by contrast, is a portable artifact.
Infrastructure lock-in. If a platform runs on one cloud only (GameLift is AWS-only), your sessions can’t move to another provider, to your own bare metal, or across regions a single vendor doesn’t serve — and there is no cross-provider failover if that vendor has an incident.
Pricing & egress lock-in. The subtlest form. A discount that only applies while you stay fully inside one ecosystem is lock-in by another name — you keep the benefit only as long as you don’t leave. Egress fees are a related trap: when moving your traffic out of a provider carries a per-gigabyte cost, the bill itself discourages you from going multi-cloud.
Matchmaker & data lock-in. When hosting is coupled to a proprietary matchmaker, or your player data has to flow into the platform to run placement, migrating means rebuilding your matchmaking — not just your hosting.
Operational lock-in. Fleet models, config formats, and IAM or CloudFormation templates encode your operations into one vendor’s control plane. The more of your ops that lives in vendor-specific tooling, the higher the exit cost.
How to measure it
Lock-in comes down to one question: what does it cost to leave? Concretely —
- Is your server a portable container image, or does it embed vendor code?
- Can the same build run on multiple providers, or on your own hardware?
- Is any pricing benefit contingent on staying exclusive to one platform?
- Is your matchmaker decoupled from your host?
- How much of your operations is written in vendor-specific config?
The more “yes, portable” answers, the lower your lock-in — and the more leverage you keep on price and performance.
How to avoid it
Low lock-in comes from keeping the integration surface small and standard. Gameye is built this way: your server is a plain Docker image with no SDK inside it; it runs across 21 providers plus bare metal — or your own hardware via BYOI; bandwidth is included, so egress never taxes a move; and any HTTP matchmaker (Nakama, Pragma, FlexMatch in standalone, or a custom backend) allocates sessions through one REST call. Nothing about your game is welded to the platform: if you ever want to leave, you take the image with you.