# Open Match: a Kubernetes matchmaking framework where you write the matching logic

> Open Match is a Go framework for building game matchmakers on Kubernetes. It handles the queueing and orchestration; you supply the function that decides who plays whom. The last push to the repository was on 2026-07-12, and the newest tagged release is v1.8.1 from 2023-12-13.

**googleforgames/open-match** — Flexible, extensible, and scalable video game matchmaking.

- Repository: https://github.com/googleforgames/open-match
- Website: http://open-match.dev
- Stars: 3,423 · Forks: 358
- Language: Go
- License: Apache-2.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/googleforgames-open-match

## The matchmaking problem Open Match puts in your hands

Most games need to answer one question repeatedly: given the players waiting right now, which of them should be placed in the same session? A naive implementation sorts players by skill and slices the list. That works until you add regions, party sizes, latency budgets, game modes and a rule that friends should not face each other. At that point the queue logic becomes a service of its own, with its own scaling problems.

Open Match is aimed at that second stage. The README describes it as an open source game matchmaking framework that simplifies building a scalable and extensible Matchmaker, and states that it gives the game developer full control over how to make matches while removing the burden of running a production service at scale. The intended audience is a studio with a Kubernetes deployment and engineers who can write Go, because the matching decision itself is not something the framework makes for you. It is the part you supply.

## Tickets, profiles and the match function loop

The architecture visible in the repository is a set of services plus a user-written component. Players enter the system as tickets, which carry the attributes a game wants to match on. The framework stores and indexes those tickets, and on a schedule it hands batches of them to a match function that the developer writes. That function returns proposals, and the framework evaluates and returns the resulting matches.

The split matters because it separates two kinds of work. Queueing, storage and orchestration are the framework's job and run as services in the cluster. The policy question, which tickets belong together, stays in code the game team owns and can change without forking the project. The repository layout reflects this: there is an api/ directory for the protocol definitions, cmd/ for the binaries, internal/ and pkg/ for the implementation, and examples/ split into demo/, functions/ and scale/. The examples/functions/ directory is where a reader should look first, because that is the shape of the code they will actually write. The go.mod file sets the module path to open-match.dev/open-match and declares Go 1.21, so a match function is a Go program that imports the project's API packages.

## Installing Open Match on a local cluster and running the demo

The Makefile is the entry point, and its help text lists the supported paths. For a local run it documents Minikube, which requires VirtualBox, and KinD. The KinD path is the shorter one, and the Makefile is explicit that a command must be run before pushing the Helm chart.

```bash
make create-kind-cluster get-kind-kubeconfig
make push-helm
```

The first line creates the cluster and exports the kubeconfig needed to talk to it. The second installs Helm into that cluster. The Makefile notes that this step finishes the KinD setup.

```bash
make push-images -j$(nproc)
make install-chart
```

These two build and push the container images and then deploy the chart. After this the Open Match services should be running in the cluster. The Makefile also exposes telemetry through port forwards, which is how you inspect what the matchmaker is doing:

```bash
make proxy-prometheus
make proxy-grafana
make proxy-ui
```

For a first real use, the examples/demo/ directory is the intended starting point, and the README points to the Open Match website for demo instructions. A GKE path exists as well, documented in the Makefile as make activate-gcp-apis followed by make create-gke-cluster push-helm, which requires gcloud to be installed and initialized.

## Where Open Match is the wrong tool

The framework assumes Kubernetes. Every documented install path in the Makefile creates a cluster: Minikube, KinD or GKE. There is no single-binary mode described in the README, and no path for a team running bare metal or a non-Kubernetes orchestrator. If your game servers are not already scheduled by Kubernetes, adopting Open Match means adopting a second orchestration system alongside whatever you use now.

A second constraint is the division of labour. Because the match function is user code, the framework cannot fix a bad matching policy. Teams that expect to configure matchmaking through settings will find that the interesting decisions live in Go source. The README does not document a rollback procedure for a deployed chart, and the Makefile's teardown targets (make delete-kind-cluster, make delete-gke-cluster, make delete-mini-cluster) remove the cluster rather than reverting a release. Anyone deploying to production needs a release strategy of their own.

There is also a release cadence question. The newest tagged release in the repository is v1.8.1, published on 2023-12-13, and the version variable in the Makefile is set to 1.8.1. The last push to the default branch was on 2026-07-12, so the branch has moved since that tag. A team that pins to a release is pinning to code that is more than two years older than the branch tip.

## How Open Match differs from a hosted matchmaking service

The obvious alternative for many teams is a managed matchmaking service tied to a backend platform, where the queue, the skill rating and the placement logic are all provided and the developer configures rules rather than writing them. The difference in approach is where the policy lives. A managed service keeps the matching algorithm inside the vendor's system, which means you get it working quickly and you accept its model of skill, latency and party composition. Open Match inverts that: the framework provides the queue and the orchestration, and the algorithm is a function you deploy. You can match on any attribute a ticket carries, and you can change the policy by shipping new code rather than waiting for a feature.

The cost of that inversion is operational. A managed service has no cluster for you to run. Open Match gives you a set of services, a Helm chart, telemetry through Prometheus and Grafana, and a Makefile full of cluster lifecycle commands. The trade is control for responsibility, and it is only worth taking if the matching policy is something your game actually differentiates on.

## Licence, maintenance and the cost of upgrading

Open Match is licensed under Apache-2.0, and the LICENSE file sits at the repository root. That is a permissive licence with an explicit patent grant and a requirement to preserve notices. It does not impose copyleft obligations on the match function you write. This is a description of the licence text, not legal advice; teams with unusual distribution models should read the file themselves.

The upgrade cost is shaped by the release history. v1.8.0 was published on 2023-09-08, v1.8.0-rc.1 on 2023-08-31 and v1.8.1 on 2023-12-13. The Makefile pins BASE_VERSION to 1.8.1, so the build tooling and the newest tag are aligned. Since the last push was on 2026-07-12, the branch carries roughly two and a half years of changes that no tag covers. A team that wants released artifacts should track the v1.8.x line; a team that wants recent fixes has to build from the branch and accept the version string the Makefile generates, which appends the short commit SHA to 1.8.1.

## Conclusion

Open Match suits teams already running Kubernetes who need custom matchmaking logic and are willing to own the match function, the profiles and the cluster. It is the wrong choice for a small game that can accept a simple skill-bucket queue, and for anyone who wants a hosted service with no operational surface. Before adopting it, check that the v1.8.1 chart installs on your cluster version, read the examples/demo directory to understand the ticket and profile flow, and confirm that the last push on 2026-07-12 included changes you actually need, since the newest tagged release predates it by more than two years.

## FAQ

### What is Open Match?

It is an open source game matchmaking framework from googleforgames, written in Go and licensed under Apache-2.0. The README describes it as simplifying the building of a scalable and extensible Matchmaker while giving the developer full control over how matches are made.

### What does Open Match need to run?

The documented install paths all create a Kubernetes cluster: Minikube (which the Makefile says requires VirtualBox), KinD, or GKE via gcloud. The Makefile then pushes images and installs the Helm chart.

### Do I have to write the matching logic myself in Open Match?

Yes. The framework handles queueing and orchestration, and the match function that decides which tickets belong together is code the game team supplies. The examples/functions/ directory in the repository shows the shape of that code.

### Which version of Open Match is the newest release?

The newest tagged release in the repository is v1.8.1, published on 2023-12-13. The Makefile sets BASE_VERSION to 1.8.1, and the last push to the default branch was on 2026-07-12.

## Sources

- [googleforgames/open-match on GitHub](https://github.com/googleforgames/open-match)
- [License: Apache-2.0](https://github.com/googleforgames/open-match/blob/main/LICENSE)
- [Project website](http://open-match.dev)
- [README](https://github.com/googleforgames/open-match/blob/main/README.md)
- [Releases](https://github.com/googleforgames/open-match/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/googleforgames-open-match