Architecture

The simplest self-hosted setup is one Linux box. The application is our simple Go binary (ggscale-server) that is the control plane: authentication, game server management, matchmaking, lobbies, leaderboards, player data storage, and friends. It needs a Postgres database, which can sit on the same box or be from a managed Postgres provider like Supabase or AWS.

    
flowchart LR
    players@{ shape: stadium, label: "Players" }

    subgraph host["Host"]
        cp@{ shape: rect, label: "ggscale server" }
    end

    db@{ shape: cyl, label: "Postgres" }

    players --> cp
    cp --> db

    classDef edge fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#0d47a1
    classDef ctrl fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#e65100
    classDef data fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#4a148c
    class players edge
    class cp ctrl
    class db data

Two optional add-ons sit alongside the core, picked per game.

Dynamic Dedicated Game Server Management Via Kubernetes and Agones. Studios that want authoritative game servers (the kind needed for ranked, esports, or anything where cheating cannot be tolerated) can add a Kubernetes and a Agones game fleet cluster. The control plane allocates pods, the game runs the needed game logic server-side, and the stack supports rolling deploys, graceful drain, and concurrent player usage metrics.

    
flowchart LR
    players@{ shape: stadium, label: "Players" }

    subgraph cphost["Control plane host"]
        cp@{ shape: rect, label: "ggscale server" }
        db@{ shape: cyl, label: "Postgres" }
    end

    subgraph k8s["kubernetes cluster"]
        agones@{ shape: hex, label: "Agones controller" }
        gs@{ shape: procs, label: "Game server pods" }
    end

    players --> cp
    players --> gs
    cp --- db
    cp --> agones
    agones --> gs

    classDef edge fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#0d47a1
    classDef ctrl fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#e65100
    classDef data fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#4a148c
    classDef cluster fill:#e8f5e9,stroke:#388e3c,stroke-width:2px,color:#1b5e20
    class players edge
    class cp ctrl
    class db data
    class agones,gs cluster

Simple Peer to Peer Game Matching and Play. For simpler multiplayer games like co-op, casual, and games with less advanced multiplayer feature requirements, the service can help match players and issue short-lived credentials for managing peer connections. Players can connect directly when their preferences and NAT allow it, or with a relay fallback otherwise. Peer to peer game connections are 10x to 100x less resource intensive than running a dedicated game server, and as a result are much cheaper to maintain. The trade-off is inconsistent connection quality, increased difficulty in enforcing strict game logic and preventing cheating. Players can set preferences for which players they want to match with via a friends system or via a public matchmaking system to discover new players.

The game developer picks the online game backend they need. For Ranked and competitive games or advanced online games like MMOs, they can use a fleet of authoritative servers while co-op and simpler games can be played via Peer to Peer connections.