[Sandbox] Agones

[thisisnotapril]

Project summary

Kubernetes for game servers

Project description

Agones is a library for hosting, running, and scaling dedicated game servers on Kubernetes. It allows for multiplayer dedicated game servers anywhere.

Org repo URL (provide if all repos under the org are in scope of the application)

n/a

Project repo URL in scope of application

https://github.com/googleforgames/agones

Additional repos in scope of the application

No response

Website URL

https://agones.dev/site/

Roadmap

https://github.com/googleforgames/agones/blob/main/docs/governance/release_process.md

Roadmap context

n/a

Contributing guide

https://github.com/googleforgames/agones/blob/main/CONTRIBUTING.md

Code of Conduct (CoC)

https://github.com/googleforgames/agones/blob/main/code-of-conduct.md

Adopters

No response

Maintainers file

https://github.com/googleforgames/agones/blob/main/OWNERS

Security policy file

https://github.com/googleforgames/agones?tab=security-ov-file#readme

Standard or specification?

n/a

Business product or service to project separation

This project is unrelated to any product or service.

Why CNCF?

Since Agones is tightly coupled to Kubernetes, CNCF is the logical home for the project. Agones being in the CNCF allows for a broader community contributor ecosystem.

Benefit to the landscape

This project brings a new gaming offering to the CNCF, one that is already used in production by many.

Cloud native 'fit'

This project is a specific use case for Kubernetes, and therefore ties directly into the cloud native ecosystem.

Cloud native 'integration'

Kubernetes

Cloud native overlap

Kubernetes

Similar projects

https://github.com/openkruise/kruise-game

Landscape

I don't think so - but the search feature isn't working on the page so I can't be sure.

Trademark and accounts

• If the project is accepted, I agree to donate all project trademarks and accounts to the CNCF

IP policy

• If the project is accepted, I agree the project will follow the CNCF IP Policy

Will the project require a license exception?

n/a

Project "Domain Technical Review"

not yet

Application contact email(s)

anassi@google.com
mark.mandel@gmail.com

Contributing or sponsoring entity signatory information

If an organization:

Google LLC. Who signs TBD but April is your main POC and will coordinate.

Name	Address	Type (e.g., Delaware corporation)	Signatory name and title	Email address

CNCF contacts

Chris Aniszczyk
Bob Killen
Jeff Sica
Jorge Castro

Additional information

No response

[markmandel]

For adopters - you can grab the list from here: https://agones.dev/site/

I'm also in the process of updating links to all the video content that exists, and there's a bunch in there as well (Playstation has been doing a lot at Kubecon lately!)

[markmandel]

Also noting that the owners file is super out of date 😄 would y'all like me to get it up to date?

[mfahlandt]

General Technical Review - Agones / Sandbox

• Project: Agones
• Project Version: 1.54.0
• Website: https://agones.dev/site/
• Date Updated: 2025-12-15
• Template Version: v1.0
• Description: Agones is an open-source platform that extends Kubernetes to orchestrate, scale, and manage the lifecycle of dedicated multiplayer game servers

Day 0 - Planning Phase

Scope

• Describe the roadmap process, how scope is determined for mid to long term features, as well as how the roadmap maps back to current contributions and maintainer ladder?
  • Agones follows a release cadence with releases occurring every 6 weeks
  • there is a kind/design label in GitHub to talkf about features Features graduate through defined stages: Alpha (experimental), Beta (enabled by feature gate), and Stable. (https://agones.dev/site/docs/guides/feature-stages/)
  • The project focuses on areas like Autoscaling improvements, Observability (metrics/tracing), and SDK expansion (Unity, Unreal, C++, etc.).
  • roadmap is primarily driven by GitHub issues and community needs
• Describe the target persona or user(s) for the project?

  • Primary: Multiplayer Game Developers (Backend/Network Engineers) building dedicated server-based games.

  • Secondary: Platform Engineers and DevOps teams at game studios responsible for scaling and managing game infrastructure.

• Explain the primary use case for the project. What additional use cases are supported by the project?

  • Primary: Orchestrating, scaling, and managing the lifecycle of dedicated game servers (stateful, in-memory simulations) on Kubernetes.

  • Additional: Multi-cluster allocation (spanning regions), maintaining "warm" fleets of servers for instant player access, and handling seamless game server updates.

• Explain which use cases have been identified as unsupported by the project.
  • Agones is not a matchmaker. It provides the APIs (Allocation) for a matchmaker to call, but does not contain matchmaking logic itself.
  • Agones is designed for authoritative server architectures, not P2P client connectivity.
• Describe the intended types of organizations who would benefit from adopting this project. (i.e. financial services, any software manufacturer, organizations providing platform engineering services)?
  • Game Development Studios (Indie to AAA)
  • Game Technology Providers (Backend-as-a-Service platforms)
  • Organizations moving legacy "bare metal" game workloads to cloud/containerized environments
• Please describe any completed end user research and link to any reports.
  • No formal user research report is linked. However, the project lists significant production adoption (Ubisoft, Embark Studios, etc.) and was originally developed in collaboration between Google and Ubisoft, implying strong user-driven design from inception

Usability

• How should the target personas interact with your project?

  • Platform Engineers: via kubectl (applying YAML for Fleets, GameServers), Helm charts, and metrics dashboards (Grafana).

  • Game Developers: via the Agones SDK integrated into the game binary (C++, C#, Go, Rust, etc.) to manage health, readiness, and shutdown signals.

• Describe the user experience (UX) and user interface (UI) of the project.
  • Agones is "headless" and API-driven. No native GUI.
  • It integrates with observability tools (Prometheus/Grafana)
  • Adopts "Kubernetes Native" patterns. Users interact with Custom Resource Definitions (CRDs) like GameServer and Fleet
• Describe how this project integrates with other projects in a production environment.
  • Kubernetes: Runs as a custom controller and operator.
  • Prometheus/Stackdriver: Exposes metrics via OpenCensus
  • Integrates with K8s networking (HostPort, NodePort) to expose UDP/TCP ports directly to players.

Design

• Explain the design principles and best practices the project is following.
  • Comes with default configurations for easy start but allows extended customization. Acts Kubernetes native by using CRDs and standard controllers. Uses a sidecar container to handle SDK communication, keep the game binary loosely coupled from the orchestration logic
• Outline or link to the project’s architecture requirements? Describe how they differ for Proof of Concept, Development, Test and Production environments, as applicable.
  • Requires a Kubernetes Cluster
  • Componentes:
    • Controller: Manages CRDs (GameServer, Fleet).
    • Sidecar: injected into GameServer Pods.
    • Allocator: (Optional) Service for handling high-throughput allocation requests.
    • Ping: (Optional) Service for latency measurement.
• Define any specific service dependencies the project relies on in the cluster.
  • Standard Kubernetes API Server
  • DNS
  • recommended cert manager
• Describe how the project implements Identity and Access Management.
  • Relying on Kubernetes RBAC for API access.
  • Supports Workload Identity for sidecar/controller permissions in cloud environments
• Describe how the project has addressed sovereignty.
  • Agones is platform-agnostic and can run on any conformant Kubernetes cluster (Public Cloud, On-Premise, or Hybrid). Although the Website only lists certain providers - room for improvement
• Describe any compliance requirements addressed by the project.
  • Not explicitly defined at the project level; compliance (GDPR, etc.) is largely delegated to the implementer's game logic and data handling.
• Describe the project’s High Availability requirements.
  • Agones Controller supports leader election for HA
  • Fleets support "Rolling Update" strategies to ensure game server capacity is maintained during upgrades.
• Describe the project’s resource requirements, including CPU, Network and Memory.

  • Controller: Minimal (configurable).

  • Sidecar: Defaults to ~30m CPU request (very lightweight) and small memory footprint

  • GameServer: Highly variable, defined by the user in the CRD based on their game's needs.

  • The baseline demo has a very slim footprint

• Describe the project’s storage requirements, including its use of ephemeral and/or persistent storage.
  • Game servers are typically ephemeral and state is held in memory.
  • For Logging / Monitoring with Prometheus persistant storage would be required
• Please outline the project’s API Design:
  • Describe the project’s API topology and conventions
    • GameServer defaults to UDP, dynamic port allocation
    • Users configure Fleets (similar to Deployments) to manage sets of GameServers.
  • Describe the project defaults
    • Defaults to UDP protocol for game traffic, using Dynamic Port Allocation (default 7000-8000 on the host node)
    • default scheduling strategy is Packed to work with Kubernetes autoscaler
  • Outline any additional configurations from default to make reasonable use of the project
    • Users can expand the default MinPort and MaxPort range in to accommodate more concurrent game sessions per node
    • Tuning the CPU/Memory requests of the Sidecar
    • Bring your own certificate
  • Describe any new or changed API types and calls - including to cloud providers - that will result from this project being enabled and used
    • Uses Loadbalancer service fromn cloud providers
    • annotates Nodes to prevent the Kubernetes Cluster Autoscaler from removing nodes that have "Allocated" game sessions
  • Describe compatibility of any new or changed APIs with API servers, including the Kubernetes API server
    • All CRDs are fully compatible with the standard Kubernetes API Server
  • Describe versioning of any new or changed APIs, including how breaking changes are handled
    • Versioning Scheme follows Kubernetes conventions
• Describe the project’s release processes, including major, minor and patch releases.
  • Cadence: Minor releases every 6 weeks.
  • Patch: As needed for critical bugs/security.
  • Automation: Release process is documented and likely automated via Cloud Build/Actions (referenced in contribution guide).

Installation

• Describe how the project is installed and initialized, e.g. a minimal install with a few lines of code or does it require more complex integration and configuration?
  • Standard: Helm Chart (helm install agones/agones).
  • Minimal/Dev: kubectl apply -f install.yaml (YAML manifest).
• How does an adopter test and validate the installation?
  • Users can deploy a simple game server example provided in the docs and use netcat to verify lifecycle and connectivity

Security

• Please provide a link to the project’s cloud native security self assessment.
  • have not found any
• Please review the Cloud Native Security Tenets from TAG Security.
  • How are you satisfying the tenets of cloud native security projects?
    • Agones is recommended to be installed in a dedicated namespace
    • the "Allocator" service (used by matchmakers to request servers) defaults to strict mTLS authentication, requiring client certificates rather than open HTTP access.
    • it uses the Sidecar pattern. the game server container (user code) does not have direct access to the Kubernetes API. Instead, it communicates via a local SDK (HTTP/gRPC over localhost) to the Agones Sidecar, which acts as a proxy
  • Describe how each of the cloud native principles apply to your project.
    • The RBAC role for the GameServer sidecar is scoped to get and update only the specific GameServer resource it is attached to. It cannot list other game servers or modify cluster state
    • Admission Webhooks validate GameServer specifications before they are applied to the cluster
  • How do you recommend users alter security defaults in order to "loosen" the security of the project? Please link to any documentation the project has written concerning these use cases.
    • Potential disbalement of RBAC
    • https://agones.dev/site/docs/installation/install-agones/helm/
    • Potenial disablement of mtls for dev
    • https://agones.dev/site/docs/installation/install-agones/helm/
• Security Hygiene
  • Please describe the frameworks, practices and procedures the project uses to maintain the basic health and security of the project.
    • Vulnerability Reporting: Security issues should be reported to security@agones.dev or via the Google Vulnerability Reward Program (VRP). (https://github.com/googleforgames/agones?tab=security-ov-file#readme)
    • Extensive Test Suite
    • https://github.com/googleforgames/agones/blob/main/build/docs/building-testing.md
  • Describe how the project has evaluated which features will be a security risk to users if they are not maintained by the project?
• Cloud Native Threat Modeling
  • Explain the least minimal privileges required by the project and reasons for additional privileges.
    • controller requires cluster wide permissions
      • due acting as a custom scheduler
    • allocator requires create pemissions on secrets and services
    • gameserver requires get and update on own crd
  • Describe how the project is handling certificate rotation and mitigates any issues with certificates.
    • Helm chart automatically generates self-signed certificates for the Admission Webhooks and the Allocator service during installation
    • (https://agones.dev/site/docs/advanced/allocator-service/#certificates)
  • Describe how the project is following and implementing secure software supply chain best practices
    • Builds are automated (google cloud build) (https://github.com/googleforgames/agones/blob/main/cloudbuild.yaml)
    • images are published to artifact registry

---

Gouvernance quick check

OWNERS File - need to be updated last change 2 years ago
Meetings: project hosts monthly Community Meetings which are open to the public. They maintain a shared calendar
CoC: uses the standard Contributor Covenant (v1.4) (https://github.com/googleforgames/agones/blob/main/code-of-conduct.md)
Contributions: While having two main contributors there is a broader contributor base, in the past 12 months from different organisations

---

Questions:

Is there a long term road map, currently it seems heavily issue driven.
Is there any work being done on signing images / generating SBOMS?

---

Personal Opinion
Agones is a well defined and well established project. That should be taken into the CNCF on Sandbox Level. It excells at various points already Sandbox. (Release Management, Stability, Size)
Improvments should be done in Project Timelines and Feature decission process

[markmandel]

Just answering some questions:

Is there a long term road map, currently it seems heavily issue driven.

We are very issue and community driven. We have long term contributors from Google Cloud, but they don't tend to lead efforts (much?) these days, but definitely do some great KTLO. I'll let them chime in if they so desire on their roadmap / input. But overall, I'd say we are very community and issue driven.

Is there any work being done on signing images / generating SBOMS?

I don't think so? 🤔 (but I'm not familiar with this space) all our images are on Google Cloud Artifact registry - so I'm guessing it's possible to do this, especially if this is a standard security practice. I don't have access to the GCP project anymore, so I can't check. At time I left Google we were running immutable images in the registry.