We want online game hosting to be open, portable, and easy to run.
WordPress and projects like Ghost made web publishing easier to own and operate with two things: a free, open-source codebase that runs on a small commodity server, and a managed tier for people who never wanted to run a server. Many websites still run on it today. We want a similar setup for multiplayer game backends, because too many online games offer limited player community control or stop working when their official servers shut down.
A Platform for Multiple Audiences
ggscale serves three groups, and the same backend code handles all of them.
Developers launching new games. Indie studios and smaller publishers get a cheap, no-lock-in backend. They self-host on a small VPS or use ggscale Cloud as a managed service. The open-source path also gives them a clean answer for what happens when the title eventually winds down.
Publishers ending a live-service title. When a studio decides to shut a multiplayer game down, ggscale offers a paid service to port it onto the open-source stack. The community can then run the game themselves, the publisher hands off ownership cleanly, and nobody has to write an offline-mode patch from scratch.
Player communities: helps keep games alive and lets you host your own game servers. For current games that ship on ggscale, communities can stand up their own server: with optional mod support, in their own region, for tournaments, or just for a group of friends. When a publisher sunsets a multiplayer title, an active community can pick up the same backend the studio used and keep playing. None of it depends on the publisher’s central infrastructure.
A studio that ships a game to use ggscale at launch can use the same infrastructure their community will host on it later.
The Problem
When a publisher shuts an online game’s servers down, much of the game stops working. Sometimes the studio has closed. Sometimes the title is no longer earning enough to operate. Sometimes a corporate strategy shift leaves the project behind. The cause varies, but the result is the same: players lose access to a game they expected to keep playing.
The Stop Killing Games movement has spent the last few years arguing this should change. The request is reasonable: when a publisher sunsets a multiplayer title, players should get a self-host path, an offline mode, or a refund.
The genuine challenge the game industry faces is that retrofitting an offline or self-hosted path into a shipped multiplayer game is really difficult and resource intensive. The authentication code has to work with PlayStation Network, Xbox Live, Steam, or Epic. Player progression is woven through proprietary services. Matchmaking sits behind closed-source orchestration. Friends and presence depend on platform-specific social graphs, and the data inside them is regulated by GDPR. Handing the community a working server isn’t a flag flip; it’s months of unfunded engineering on a title that is no longer earning money.
Both sides have a point. The community is asking for something the industry isn’t delivering yet.
Sustainable Value for Players and Developers
ggscale gives developers and communities the core tools for an online game: dedicated servers, peer-to-peer connections, matchmaking, authentication, player data, leaderboards, and lobbies. The same stack gives studios a cleaner exit when a title winds down; less proprietary code has to be replaced, and players have a path to keep the game running.
Deployment is simple, like setting up a Ghost or WordPress site. The control plane is a single Go binary: put it on a Linux box, point it at Postgres, configure email, and run it. Included are docker compose files you can use for either simple deployments or you can bring up the the full tech stack with ggscale-server, Postgres, Prometheus, and the dev observability tools together.
Portability is the source, the binary, and your exported Postgres data. Dynamic game server management runs through a plugin system, so ggscale can create servers on Docker, K3s with Agones, or supported cloud backends. Supporting multiple backends matters because it keeps the platform useful across different hosting environments and reduces vendor lock-in.
Players and developers who do not want to operate the stack can use ggscale Cloud, the hosted service we run. It keeps the same open core as the self-hosted version and adds hosted features like advanced analytics, monitoring, enterprise SSO, and fine-grained permissions.
How Preservation Actually Works
Open-source licensing. To encourage long term community use and contribution, we rely heavily on only Open Source Initiative (OSI)-approved open source licenses. We use a community friendly Apache 2.0 license that other great open source projects use as well. A studio that builds on the gg-scale service now owns a working backend they can keep running, fork, or hand to a community without renegotiating any license. You get the core features you need with simple open source licensing.
SDKs that simplify the move to open source. The Go and C# SDKs follow standard patterns and sit behind a small set of well-defined interfaces. A studio swapping in ggscale to replace a proprietary backend integrates against that surface instead of taking on an open-ended rewrite.
Self-hosted or managed cloud. Studios that want to operate their own backend can run the Go binary on a Linux box. Studios that don’t want to operate anything can use ggscale Cloud. Either path reduces the challenges of developing and managing a game on bespoke-backend platforms and avoids the lock-in of having to maintain a proprietary stack forever.
Architecture
See the Architecture page for deployment diagrams and how the core system, Kubernetes/Agones, and peer-to-peer modes fit together.