cncf
[Sandbox] Agones
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
- [x] If the project is accepted, I agree to donate all project trademarks and accounts to the CNCF
IP policy
- [x] 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)
[email protected] [email protected]
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
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!)
Also noting that the owners file is super out of date 😄 would y'all like me to get it up to date?
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 API topology and 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/
- How are you satisfying the tenets of cloud native security projects?
- 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 [email protected] 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?
- Please describe the frameworks, practices and procedures the project uses to maintain the basic health and security of 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
- controller requires cluster wide permissions
- 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
- Explain the least minimal privileges required by the project and reasons for additional privileges.
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
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.
Follow-up question - this would mean some migration is needed for the project should it be accepted to the CNCF to move away from Goolge Infra? (Given the circumstance that one of the main Maintainers does not have access to Infra)
@thisisnotapril was the plan to move the google cloud owned infra into CNCF?
Vote created
@mrbobbytables has called for a vote on [Sandbox] Agones (#440).
The members of the following teams have binding votes:
| Team |
|---|
| @cncf/cncf-toc-voters |
Non-binding votes are also appreciated as a sign of support!
How to vote
You can cast your vote by reacting to this comment. The following reactions are supported:
| In favor | Against | Abstain |
|---|---|---|
| 👍 | 👎 | 👀 |
Please note that voting for multiple options is not allowed and those votes won't be counted.
The vote will be open for 2months 30days 2h 52m 48s. It will pass if at least 66% of the users with binding votes vote In favor 👍. Once it's closed, results will be published here as a new comment.
![git-vote[bot] avatar](https://avatars.githubusercontent.com/in/206179?v=4 "Published by a pub.dev verified publisher"){kind=small}
@thisisnotapril we'll need a signatory from Google if the TOC votes to accept :)
[@thisisnotapril
](https://github.com/thisisnotapril) was the plan to move the google cloud owned infra into CNCF?
Yes because we want it to be accessible to all the maintainers. I defer to Bob and crew on the timeline for that.
Vote status
So far 63.64% of the users with binding vote are in favor and 0.00% are against (passing threshold: 66%).
Summary
| In favor | Against | Abstain | Not voted |
|---|---|---|---|
| 7 | 0 | 0 | 4 |
Binding votes (7)
| User | Vote | Timestamp |
|---|---|---|
| angellk | In favor | 2025-12-16 16:50:23.0 +00:00:00 |
| chira001 | In favor | 2025-12-16 16:47:39.0 +00:00:00 |
| dims | In favor | 2025-12-16 16:48:53.0 +00:00:00 |
| kevin-wangzefeng | In favor | 2025-12-18 14:22:16.0 +00:00:00 |
| kfaseela | In favor | 2025-12-16 16:49:42.0 +00:00:00 |
| linsun | In favor | 2025-12-16 16:38:51.0 +00:00:00 |
| rochaporto | In favor | 2025-12-16 16:38:44.0 +00:00:00 |
| @chadbeaudin | Pending | |
| @TheFoxAtWork | Pending | |
| @jeremyrickard | Pending | |
| @kgamanji | Pending |
Non-binding votes (12)
| User | Vote | Timestamp |
|---|---|---|
| lacroixthomas | In favor | 2025-12-16 16:38:01.0 +00:00:00 |
| nrwiersma | In favor | 2025-12-16 16:41:28.0 +00:00:00 |
| swermin | In favor | 2025-12-16 16:49:59.0 +00:00:00 |
| HerrSammyDE | In favor | 2025-12-16 18:11:51.0 +00:00:00 |
| markmandel | In favor | 2025-12-16 21:29:58.0 +00:00:00 |
| thisisnotapril | In favor | 2025-12-16 21:37:26.0 +00:00:00 |
| t3-aoki | In favor | 2025-12-17 0:46:53.0 +00:00:00 |
| katsew | In favor | 2025-12-17 1:31:13.0 +00:00:00 |
| peterton | In favor | 2025-12-17 8:44:30.0 +00:00:00 |
| keith-miller | In favor | 2025-12-17 16:03:49.0 +00:00:00 |
| mikeseese | In favor | 2025-12-17 16:40:06.0 +00:00:00 |
| txuna | In favor | 2025-12-17 23:03:47.0 +00:00:00 |
In case it helps push the voting through, just updated https://agones.dev/site/docs/third-party-content/ with a stack more videos, articles and podcasts - highlighting a huge number of case studies and users, from Playstation, to Nintendo, Bandai Namco, SEGA, Krafton and more. 😁
Vote closed
The vote passed! 🎉
72.73% of the users with binding vote were in favor and 0.00% were against (passing threshold: 66%).
Summary
| In favor | Against | Abstain | Not voted |
|---|---|---|---|
| 8 | 0 | 0 | 3 |
Binding votes (8)
| User | Vote | Timestamp |
|---|---|---|
| @angellk | In favor | 2025-12-16 16:50:23.0 +00:00:00 |
| @chira001 | In favor | 2025-12-16 16:47:39.0 +00:00:00 |
| @dims | In favor | 2025-12-16 16:48:53.0 +00:00:00 |
| @jeremyrickard | In favor | 2025-12-21 1:23:58.0 +00:00:00 |
| @kevin-wangzefeng | In favor | 2025-12-18 14:22:16.0 +00:00:00 |
| @kfaseela | In favor | 2025-12-16 16:49:42.0 +00:00:00 |
| @linsun | In favor | 2025-12-16 16:38:51.0 +00:00:00 |
| @rochaporto | In favor | 2025-12-16 16:38:44.0 +00:00:00 |
Non-binding votes (13)
| User | Vote | Timestamp |
|---|---|---|
| @lacroixthomas | In favor | 2025-12-16 16:38:01.0 +00:00:00 |
| @nrwiersma | In favor | 2025-12-16 16:41:28.0 +00:00:00 |
| @swermin | In favor | 2025-12-16 16:49:59.0 +00:00:00 |
| @HerrSammyDE | In favor | 2025-12-16 18:11:51.0 +00:00:00 |
| @markmandel | In favor | 2025-12-16 21:29:58.0 +00:00:00 |
| @thisisnotapril | In favor | 2025-12-16 21:37:26.0 +00:00:00 |
| @t3-aoki | In favor | 2025-12-17 0:46:53.0 +00:00:00 |
| @katsew | In favor | 2025-12-17 1:31:13.0 +00:00:00 |
| @peterton | In favor | 2025-12-17 8:44:30.0 +00:00:00 |
| @keith-miller | In favor | 2025-12-17 16:03:49.0 +00:00:00 |
| @mikeseese | In favor | 2025-12-17 16:40:06.0 +00:00:00 |
| @txuna | In favor | 2025-12-17 23:03:47.0 +00:00:00 |
| @IrvingMg | In favor | 2025-12-19 7:43:42.0 +00:00:00 |
The TOC vote for Agones has passed! 🎉 Next step: Please finalize the Contribution Agreement. This is required before official CNCF on-boarding can begin. Please reach out to CNCF Staff for assistance.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Happy New Year! I'm pretty sure that the ball is in @thisisnotapril 's court at the moment 😁 but lemme know if we on the Agones side can do anything to move things forward.
Happy New Year! I'm pretty sure that the ball is in @thisisnotapril 's court at the moment 😁 but lemme know if we on the Agones side can do anything to move things forward.
Hi @markmandel. Definitely. You can check out the issue template with onboarding tasks and begin work on those. We'll then update the actual onboarding issue when it's opened.