Oracle Cloud OKE: Agones Game Servers in 13 Steps [2026]

Most tutorials about running dedicated game servers on Kubernetes point at the same three clouds: Google Kubernetes Engine, Amazon EKS, or Azure Kubernetes Service. Oracle Cloud Infrastructure rarely comes up, even though Oracle Container Engine for Kubernetes (OKE) is CNCF-certified, ships a genuinely free cluster control plane tier, and has been an officially documented installation target for Agones, the open-source Kubernetes game server framework, for years. As of October 2026, OKE supports Kubernetes 1.36.4 and the current stable Agones release is 1.60.0, dated September 22, 2026. That combination makes OKE one of the cheapest places to stand up a real multiplayer game server fleet without renting three separate cloud accounts just to compare prices.

This tutorial walks through the entire path: creating an OKE cluster, wiring up kubectl and the OCI CLI, installing Agones 1.60.0 with Helm, configuring load balancing for real UDP/TCP game traffic, containerizing a dedicated game server, deploying a Fleet, allocating a server to a player session, autoscaling that fleet, and adding OpenTelemetry-compatible observability. By the end you will have a working, horizontally scalable game server backend running on Oracle Cloud, and a clear dollar-for-dollar comparison against running the same workload on EKS or GKE.

Why Run Agones on Oracle Cloud’s OKE in 2026

Agones extends the Kubernetes API with custom resources — GameServer, Fleet, FleetAutoscaler, and GameServerAllocation — that let you run, health-check, and allocate dedicated game server processes the same way you’d run any other containerized workload. Agones’ own installation documentation explicitly lists Google Kubernetes Engine, Amazon EKS, Azure Kubernetes Service, Minikube, and Oracle Container Engine for Kubernetes as supported cluster targets, with a dedicated OKE setup guide at agones.dev. That matters because it means you are not duct-taping an unsupported integration together. Oracle’s own Kubernetes offering is also independently listed under the CNCF Certified Kubernetes conformance program under the product name Oracle Container Engine, so the Agones control loop behaves the same way it would on any other certified distribution, and you’re not fighting undocumented API drift.

There’s a second, less obvious reason to care about this combination in late 2026: most of the public tutorial content for Agones skews heavily toward GKE, because that’s where the project originated as a Google-backed open-source effort. That leaves a real documentation gap for teams who are already running other workloads on Oracle Cloud, or who specifically want a second cloud for disaster recovery and regional failover without duplicating a GKE or EKS bill. Oracle’s own OKE documentation hub covers cluster lifecycle management in detail, but it doesn’t walk through the game-server-specific pieces — node taints for workload isolation, host port ranges, or FleetAutoscaler tuning — that this guide fills in.

The financial case is just as real. OKE offers a Basic Cluster tier with no control-plane fee at all, while the Enhanced cluster tier (which adds virtual nodes, workload add-ons, and an SLA) costs $0.10 per cluster-hour, capped at $74.40 per month. Compare that to Amazon EKS, which charges $0.10 per cluster-hour for standard Kubernetes version support during the first 14 months after a version ships, then $0.60 per cluster-hour once a cluster moves into extended support. Google Kubernetes Engine charges a flat $0.10 per cluster-hour for both Autopilot and Standard clusters, offset by $74.40 in monthly credits per billing account — effectively one free zonal cluster a month, with credits that do not roll over and do not cover compute or regional clusters. For a side project, a load test rig, or a second region for latency-sensitive matchmaking, OKE’s Basic tier removes the control-plane cost entirely, which none of the big three currently do outright.

Prerequisites and Exact Versions You’ll Need

Pin these versions before you start. Kubernetes and Agones both move fast enough that “latest” silently breaks tutorials within a few months, so verify each with a --version flag as you go rather than trusting a number printed on a blog post from six months ago.

Tool / Resource	Version or Spec Used Here	Notes
OCI tenancy	Always Free or pay-as-you-go	Always Free now grants 2 OCPUs / 12 GB total on Ampere A1 Flex (reduced from 4 OCPUs / 24 GB on June 15, 2026)
OKE Kubernetes version	1.36.4	Newest supported as of the October 1, 2026 OKE release notes; 1.35.2 and 1.34.10 remain supported
OCI CLI	2.6.4 or later	Minimum version Oracle documents for the cluster-access workflow
kubectl	1.35.x, 1.36.x, or 1.37.x	Oracle requires kubectl within one minor version of the control plane
Helm	3.x	Used to install Agones from its official chart repository
Agones	1.60.0	Latest stable release, dated September 22, 2026
Docker or Podman	Any current release	Used to build and push the game server image to OCIR

You’ll also need a terminal with outbound HTTPS access, roughly 20 minutes of propagation time while OCI provisions your cluster’s control plane, and a basic dedicated game server binary or test image. If you don’t have one handy, this guide uses the Agones project’s own simple-game-server test image so you can validate the whole pipeline before swapping in your real game logic.

Setting Up Your Oracle Cloud Foundation

Step 1: Create Your OCI Tenancy and Enable Always Free Resources

Sign up for an Oracle Cloud account at oracle.com/cloud/free if you don’t already have a tenancy. Once inside the console, note your tenancy’s home region — OKE clusters and their node pools live in a single region, and switching later means rebuilding. Confirm your Always Free entitlements under Governance > Limits, Quotas and Usage. As of mid-2026 the Always Free Ampere A1 Flex allowance is 1,500 OCPU-hours and 9,000 GB-hours per month, which works out to roughly 2 OCPUs and 12 GB of memory if you run continuously — down from the 4 OCPUs and 24 GB figure that circulated in older tutorials before Oracle’s June 15, 2026 reduction. You also get 200 GB of Always Free block storage (including boot volumes, plus five volume backups) and 10 TB of outbound data transfer per month. Two AMD-based VM.Standard.E2.1.Micro instances are included separately from the Ampere allowance.

That 2 OCPU / 12 GB Ampere ceiling is tight for a production fleet but genuinely workable for development, CI load tests, or a low-player-count regional server. Budget accordingly: a 3-node cluster described later in this guide will exceed Always Free Ampere capacity and incur standard Compute charges unless you shrink node count or shape size.

Step 2: Install and Configure the OCI CLI

Install the OCI CLI (2.6.4 or newer) and run the interactive setup wizard, which generates an API signing key pair and writes your config to ~/.oci/config.

bash -c "$(curl -L https://raw.githubusercontent.com/oracle/oci-cli/master/scripts/install/install.sh)"
oci --version
oci setup config
oci iam region list --query "data[].{Name:name,Key:key}" --output table

If oci --version reports anything older than 2.6.4, upgrade before continuing — the cluster-access and kubeconfig-generation commands used later depend on a current CLI build.

Step 3: Create Your OKE Cluster

You can create a cluster through the console’s Quick Create wizard, but the CLI gives you a repeatable record of exactly what you built. Choose the Basic Cluster tier if you want to skip the control-plane fee entirely, or Enhanced if you need virtual nodes, workload identity principals, or add-ons later — Enhanced costs $0.10 per cluster-hour, capped at $74.40 a month, so even that tier is predictable.

oci ce cluster create 
  --compartment-id ocid1.compartment.oc1..your_compartment_ocid 
  --name agones-oke-demo 
  --kubernetes-version v1.36.4 
  --vcn-id ocid1.vcn.oc1..your_vcn_ocid 
  --service-lb-subnet-ids '["ocid1.subnet.oc1..your_lb_subnet_ocid"]' 
  --cluster-pod-network-options '[{"cniType":"OCI_VCN_IP_NATIVE"}]' 
  --type BASIC_CLUSTER 
  --wait-for-state ACTIVE

Provisioning typically takes several minutes. Verify the exact version string OCI exposes in your target region before you run this, since staged rollouts mean 1.36.4 may appear a few days later in some regions than others.

Connecting and Sizing Your Cluster

Step 4: Connect kubectl to OKE

Generate a kubeconfig file scoped to your new cluster, then confirm connectivity.

oci ce cluster create-kubeconfig 
  --cluster-id ocid1.cluster.oc1..your_cluster_ocid 
  --file $HOME/.kube/config 
  --region us-ashburn-1 
  --token-version 2.0.0 
  --kube-endpoint PUBLIC_ENDPOINT

kubectl version --client
kubectl get nodes -o wide

Expected output once nodes are ready:

NAME           STATUS   ROLES   AGE   VERSION   INTERNAL-IP
10.0.10.2      Ready    node    4m    v1.36.4   10.0.10.2
10.0.10.3      Ready    node    4m    v1.36.4   10.0.10.3
10.0.10.4      Ready    node    4m    v1.36.4   10.0.10.4

If kubectl reports a version mismatch warning, remember Oracle’s compatibility rule: your client must stay within one minor version of the control plane, so for a 1.36.4 cluster, kubectl 1.35, 1.36, or 1.37 all work.

Step 5: Size and Label Your Game-Server Node Pool

Agones recommends isolating game server workloads onto dedicated nodes so system pods and player-facing processes don’t compete for CPU during a traffic spike. Create a node pool, taint it, and label it so your Fleet manifests can target it specifically.

kubectl label nodes 10.0.10.3 10.0.10.4 agones.dev/role=game-server-node
kubectl taint nodes 10.0.10.3 10.0.10.4 dedicated=gameserver:NoExecute

If you’re staying inside the Always Free Ampere A1 allowance, size your pool conservatively — 2 OCPUs and 12 GB total means roughly two small nodes, or one node big enough to run a handful of test game server pods. Anything beyond that moves you onto standard Compute billing for the extra OCPUs and memory.

Installing Agones 1.60 on Oracle Cloud’s OKE

Step 6: Install Helm and Add the Agones Repository

helm repo add agones https://agones.dev/chart/stable
helm repo update
helm search repo agones --versions | head -5

Step 7: Install Agones 1.60.0 and Verify the CRDs

kubectl create namespace agones-system
helm install agones agones/agones 
  --namespace agones-system 
  --version 1.60.0 
  --set gameservers.namespaces="{default}"

kubectl get pods -n agones-system
kubectl get crds | grep agones.dev

A healthy install shows the controller, allocator, and ping pods running, plus five Agones custom resource definitions:

NAME                                  READY   STATUS    RESTARTS   AGE
agones-allocator-7f9d6c8b4-k2m9x      1/1     Running   0          58s
agones-controller-5b7f9c9d6-p7q2r     1/1     Running   0          58s
agones-ping-6d8f7b5c4-x4t8w           1/1     Running   0          58s

fleets.agones.dev
gameservers.agones.dev
gameserverallocations.agones.dev
gameserversets.agones.dev
fleetautoscalers.agones.dev

If the controller pod sits in CrashLoopBackOff, check kubectl logs on it before moving forward — the most common cause at this stage is a Helm value mismatch between the targeted namespace and the one you created.

Networking for Game Traffic: Load Balancers and Ports

Step 8: Configure the OCI Load Balancer for Game Traffic

Agones exposes each game server pod on a dynamically allocated host port by default, which works directly with OCI’s networking without needing a load balancer in front of every single server — matchmakers connect players straight to the allocated node IP and port. Where a load balancer is useful is for the Agones allocator service itself, or for any HTTP-based matchmaking API you run alongside it. Be deliberate about the Always Free Flexible Load Balancer’s limits if you’re using one: it caps out at 10 Mbps of bandwidth, 16 listeners, 16 virtual hostnames, 16 backend sets, and 1,024 backend servers per eligible tenancy. That bandwidth ceiling is fine for a control-plane API or matchmaking endpoint, but it is not enough for routing live UDP game traffic for more than a handful of concurrent sessions — plan on a paid Network Load Balancer, or route traffic directly to node ports, once you move past testing.

# Confirm which host ports Agones assigned to your game server pods
kubectl get gameservers -o json | 
  jq '.items[].status | {address: .address, port: .ports[0].port}'

Also open the correct security list or network security group rules for your node pool’s subnet — Agones’ default host port range is 7000–8000, and traffic on that range needs to be explicitly allowed for both TCP and UDP depending on your game’s transport protocol.

Containerizing Your Game Server for OCIR

Step 9: Build and Push a Game Server Image to Oracle’s Container Registry

OCIR (Oracle Cloud Infrastructure Registry) follows the same workflow as any OCI-compliant registry: tag, authenticate, push. Repository paths follow the pattern <region-key>.ocir.io/<tenancy-namespace>/<repository>:<tag>.

# Dockerfile
FROM gcr.io/agones-images/simple-game-server:0.33
EXPOSE 7654/udp
ENTRYPOINT ["/simple-game-server"]

docker build -t iad.ocir.io/yourtenancynamespace/agones-demo:1.0 .
docker login iad.ocir.io -u 'yourtenancynamespace/youruser'
docker push iad.ocir.io/yourtenancynamespace/agones-demo:1.0

If your repository is private, create an OKE image-pull secret referencing an OCI auth token rather than trying to make the repository public — private-by-default is the correct posture for anything beyond a throwaway demo.

Writing GameServer and Fleet Manifests

Step 10: Deploy a Fleet

A Fleet manages a pool of warm, ready-to-allocate GameServer pods so a player never waits on a cold container start. This manifest targets the tainted node pool from Step 5 and requests three warm replicas.

apiVersion: agones.dev/v1
kind: Fleet
metadata:
  name: agones-oke-fleet
spec:
  replicas: 3
  template:
    metadata:
      labels:
        agones.dev/role: game-server
    spec:
      ports:
        - name: default
          containerPort: 7654
          protocol: UDP
      template:
        spec:
          tolerations:
            - key: "dedicated"
              operator: "Equal"
              value: "gameserver"
              effect: "NoExecute"
          nodeSelector:
            agones.dev/role: game-server-node
          containers:
            - name: simple-game-server
              image: iad.ocir.io/yourtenancynamespace/agones-demo:1.0
              resources:
                requests:
                  cpu: "250m"
                  memory: "256Mi"
                limits:
                  cpu: "500m"
                  memory: "512Mi"

kubectl apply -f fleet.yaml
kubectl get gameservers
kubectl get fleet agones-oke-fleet -o jsonpath='{.status}'

Deploying, Allocating, and Autoscaling Your Fleet

Step 11: Request an Allocation for a Player Session

Your matchmaker calls the Agones allocator service (or applies a GameServerAllocation object directly, for testing) to claim one ready server out of the warm pool.

apiVersion: allocation.agones.dev/v1
kind: GameServerAllocation
spec:
  selectors:
    - matchLabels:
        agones.dev/fleet: agones-oke-fleet

kubectl create -f allocation.yaml -o json | jq '.status'

A successful allocation response includes the node’s address and the allocated port, which is exactly what your matchmaking service hands back to the connecting client:

{
  "state": "Allocated",
  "gameServerName": "agones-oke-fleet-7x4jk-9d2qp",
  "address": "129.80.XX.XX",
  "ports": [{ "name": "default", "port": 7302 }]
}

Step 12: Add a FleetAutoscaler

A FleetAutoscaler keeps a buffer of ready servers proportional to demand, so you never run out of warm capacity during a sudden spike or pay for fully idle capacity the rest of the time.

apiVersion: autoscaling.agones.dev/v1
kind: FleetAutoscaler
metadata:
  name: agones-oke-autoscaler
spec:
  fleetName: agones-oke-fleet
  policy:
    type: Buffer
    buffer:
      bufferSize: 2
      minReplicas: 2
      maxReplicas: 10

kubectl apply -f fleetautoscaler.yaml
kubectl get fleetautoscaler agones-oke-autoscaler

With minReplicas: 2 and maxReplicas: 10, the fleet will never scale below two warm servers and will cap out at ten under load, which keeps you inside a predictable Compute bill if you’ve sized your node pool to support that ceiling.

Adding Observability With OpenTelemetry and Prometheus

Step 13: Deploy an OpenTelemetry Collector Alongside Agones

Agones exposes Prometheus-format metrics out of the box, covering fleet allocation latency, ready/allocated counts, and game server state transitions. Deploy an OpenTelemetry Collector to scrape those metrics and forward them to whichever backend you prefer — Prometheus running inside the cluster, Grafana, or an OCI Monitoring-compatible exporter.

helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm repo update
helm install otel-collector open-telemetry/opentelemetry-collector 
  --namespace agones-system 
  --set mode=deployment 
  --set config.receivers.prometheus.config.scrape_configs[0].job_name=agones-controller 
  --set config.receivers.prometheus.config.scrape_configs[0].static_configs[0].targets[0]=agones-controller.agones-system.svc:8080

Metrics worth alerting on in production: fleet allocation latency (how long a player waits for a server), the ready-versus-allocated ratio (are you about to run dry on warm capacity), and pod restart counts (a flapping game server process usually means a crash in your actual game logic, not the orchestration layer).

Output Examples: What a Healthy Fleet Looks Like

Once everything above is wired together, kubectl get gameservers on a healthy fleet should look like this, with a mix of Ready (warm, unclaimed) and Allocated (actively serving a player) states:

NAME                            STATE       ADDRESS         PORT   NODE
agones-oke-fleet-7x4jk-9d2qp    Allocated   129.80.XX.XX    7302   10.0.10.3
agones-oke-fleet-7x4jk-m8v3z    Ready       129.80.XX.XX    7193   10.0.10.3
agones-oke-fleet-7x4jk-q2n7f    Ready       129.80.XX.XX    7044   10.0.10.4

If instead every pod is stuck in Scheduled or Creating for more than a minute or two, that’s your signal to jump to the troubleshooting section below rather than waiting it out.

Common Pitfalls When Running Agones on OKE

Assuming the old 4 OCPU / 24 GB Always Free figure still applies. Oracle cut Ampere A1 Always Free allocation to 2 OCPUs and 12 GB total on June 15, 2026. Sizing a node pool against the old number means you’ll hit a quota wall mid-deployment.
Forgetting the one-minor-version kubectl rule. Running a kubectl release more than one minor version away from your 1.36.4 control plane causes subtle API compatibility errors that don’t always surface as obvious failures.
Routing live UDP game traffic through the Always Free Flexible Load Balancer. It’s capped at 10 Mbps, which is fine for an API endpoint but will choke real-time game traffic for more than a few sessions.
Skipping node taints and tolerations. Without them, Kubernetes will happily schedule unrelated system pods onto your game-server nodes, and your game server pods onto nodes you didn’t intend, defeating the isolation the dedicated node pool was meant to provide.
Choosing the Basic Cluster tier and then needing virtual nodes later. Basic Cluster has no control-plane fee but also doesn’t support virtual nodes or the control-plane SLA — recreate as Enhanced early if you expect to need either.
Hardcoding host ports instead of letting Agones assign them. Agones’ dynamic port allocation exists specifically to avoid port collisions across co-located game server pods; hardcoding breaks that the moment you scale past one pod per node.

Troubleshooting Guide

Cluster create hangs at CREATING: usually a VCN or subnet configuration issue — confirm your service load balancer subnet CIDR doesn’t overlap with your pod network CIDR.
kubectl times out connecting: regenerate the kubeconfig with the correct --kube-endpoint flag (PUBLIC vs PRIVATE) matching how your cluster was created.
Agones controller pod in CrashLoopBackOff: check kubectl logs -n agones-system deploy/agones-controller for a namespace mismatch between the Helm install and the gameservers.namespaces value.
GameServers stuck in Scheduled state: almost always a node affinity or taint/toleration mismatch — confirm your Fleet’s nodeSelector matches the label you actually applied.
Allocation requests return no available server: your FleetAutoscaler’s buffer may be set too low for current demand, or all warm servers are already allocated — check kubectl get gameservers for the Ready count.
Players can’t connect to an allocated server: check security list / network security group rules on the node pool’s subnet for the UDP or TCP port range Agones assigned, not just the port your game code expects.
docker push to OCIR fails with 401: OCIR auth tokens expire; regenerate one from the OCI console under your user’s Auth Tokens settings and re-run docker login.
Helm install succeeds but CRDs are missing: you likely installed into a namespace that already had a partial prior release — run helm uninstall and reinstall cleanly rather than layering installs.
Nodes show NotReady after scaling the pool: check whether you’ve exceeded your Always Free Ampere A1 OCPU/memory ceiling; OCI will refuse to schedule new capacity beyond your quota without a billing method on file.

Securing Your Cluster: IAM Policies, RBAC, and Network Security Groups

A game server fleet is a bigger attack surface than most backend services, because by design it accepts unauthenticated UDP or TCP connections directly from the public internet on dozens of dynamic ports. Lock down everything around that exposed edge before you open it up. Start with OCI Identity and Access Management: create a dedicated dynamic group for your OKE node pool and scope a policy to exactly what those nodes need — pulling images from OCIR, writing logs, and reading secrets — rather than attaching a broad administrator policy out of convenience.

Allow dynamic-group agones-oke-nodes to read repos in compartment game-backend
Allow dynamic-group agones-oke-nodes to use secret-family in compartment game-backend
Allow dynamic-group agones-oke-nodes to manage objects in compartment game-backend where target.bucket.name='game-telemetry'

Layer Kubernetes RBAC on top of that IAM boundary. Agones’ controller, allocator, and ping components each need their own service accounts with narrowly scoped ClusterRole bindings — the Helm chart creates sensible defaults, but it’s worth running kubectl auth can-i --list --as=system:serviceaccount:agones-system:agones-controller after install to confirm nothing broader slipped through. At the network layer, restrict your node pool’s security list or network security group to only the ports Agones actually needs: the dynamic host port range you configured in Step 8, plus whatever health-check or admin ports your game binary exposes internally. Resist the temptation to open a wide port range “just in case” — narrowing it to the actual range you’ve configured in your Fleet manifest closes off a meaningful chunk of your exposed surface with zero functional cost.

Finally, don’t skip Kubernetes’ own admission controls. Agones ships validating webhooks for its custom resources that reject malformed Fleet or GameServer specs before they ever reach the scheduler — if you’re layering your own admission policies (OPA Gatekeeper or Kyverno, for instance) on top, test them against a staging namespace first, since an overly strict policy can silently block Agones’ own controller from reconciling game server state.

Automating Builds and Deployments With CI/CD

Manually running docker build and docker push every time you change your game server binary works for the first afternoon of testing and nowhere beyond that. Wire a pipeline so every merge to your main branch builds a new image, pushes it to OCIR, and performs a rolling update of your Fleet without downtime for already-allocated servers. Agones handles the rolling-update part natively: updating the container image in a Fleet spec spins up new GameServer pods on the new image while leaving already-Allocated servers running their current players to completion, then retires the old pods once they’re empty.

name: build-and-deploy
on:
  push:
    branches: [main]
jobs:
  build-push-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Log in to OCIR
        run: echo "${{ secrets.OCIR_AUTH_TOKEN }}" | docker login iad.ocir.io -u "${{ secrets.OCIR_USERNAME }}" --password-stdin
      - name: Build and push image
        run: |
          docker build -t iad.ocir.io/yourtenancynamespace/agones-demo:${{ github.sha }} .
          docker push iad.ocir.io/yourtenancynamespace/agones-demo:${{ github.sha }}
      - name: Update Fleet image
        run: |
          kubectl set image fleet/agones-oke-fleet simple-game-server=iad.ocir.io/yourtenancynamespace/agones-demo:${{ github.sha }}

Tag every image with the commit SHA rather than a floating latest tag — it makes rollbacks a one-line kubectl set image command instead of a scramble to figure out which build was actually running when something broke. If you’re running the Enhanced cluster tier, OKE’s workload identity support also lets your CI runner authenticate to OCIR without storing a long-lived auth token as a repository secret, which is worth the extra setup time once you’re past the prototype stage.

OKE vs EKS vs GKE: Real Cost Breakdown for Game Server Clusters

Control-plane pricing is only one line item, but it’s the line item that differs most sharply between providers, and it’s fully documented by each vendor rather than estimated.

Cloud / Tier	Control-Plane Cost	Notes
OCI OKE — Basic Cluster	$0 / month	No SLA, no virtual nodes or certain add-ons
OCI OKE — Enhanced Cluster	$0.10/cluster-hour, capped at $74.40/month	Adds virtual nodes ($0.015/node-hour extra), SLA, add-ons
AWS EKS — Standard support	$0.10/cluster-hour	Applies for 14 months after a Kubernetes version ships
AWS EKS — Extended support	$0.60/cluster-hour	Standard $0.10 plus $0.50 extended-support surcharge, next 12 months
GKE — Autopilot or Standard	$0.10/cluster-hour flat	Offset by $74.40/month credit per billing account — effectively one free zonal cluster monthly; credits don’t roll over

Both of the competing figures above come straight from the vendors’ own pricing pages — see Amazon’s EKS pricing documentation and Google’s GKE pricing page for the full breakdown, including how the extended-support clock starts counting from each individual Kubernetes version’s release date rather than from when you created the cluster. Worker node pricing across all three providers is billed at standard Compute rates for whatever shape or instance type you choose, so the control-plane line above is where OKE’s Basic tier genuinely undercuts the alternatives — it’s the only one of the three that lets you run a cluster’s control plane at zero cost indefinitely, with no credit expiration and no support-tier clock running against you. That’s a meaningful difference if you’re running a second region purely for latency testing, a staging environment that mirrors production, or a hobby project you don’t want turning into a recurring bill.

Load Testing Your Fleet Before Launch

Don’t find out your FleetAutoscaler buffer is too small on the night your game actually launches. Before opening the doors to real players, simulate concurrent allocation requests against your allocator service and watch how quickly new GameServer pods come up to replace the ones you’ve claimed. A simple loop is enough to validate the mechanics even before you reach for a dedicated load-testing tool.

for i in $(seq 1 20); do
  kubectl create -f allocation.yaml -o json | jq -r '.status.address + ":" + (.status.ports[0].port|tostring)' &
done
wait
kubectl get gameservers | sort | uniq -c -f1

Watch three things while that runs: whether allocation latency stays flat as you claim more servers, whether the FleetAutoscaler actually spins up replacement capacity before your Ready pool hits zero, and whether your node pool has enough headroom to schedule the new pods without queuing. If allocation latency climbs sharply past a certain concurrency level, that’s usually the controller reconciliation loop falling behind rather than a networking problem — increasing the bufferSize on your autoscaler or giving the controller pod more CPU headroom both help. Run this same test again after any change to your node pool shapes, your autoscaler policy, or your Agones version, since all three affect how quickly the system recovers from a burst.

Advanced Tips for Production and the Complete Working Project

A few things worth doing before you point real players at this setup. First, run multiple node pools across OCI availability domains within your region so a single domain outage doesn’t take your whole fleet offline. Second, if your game needs sub-50ms latency for specific player populations, measure actual round-trip time from representative client locations to your chosen OCI region rather than assuming geographic proximity is a reliable proxy — then stand up a second regional OKE cluster if one region can’t cover your latency targets, using the Basic tier’s zero control-plane cost to make a second region cheap to justify. Third, swap the Buffer-type FleetAutoscaler policy for a Webhook-based policy once you have real traffic data, so scaling decisions can factor in queue depth or matchmaking backlog rather than a flat warm-server count. Fourth, put your OCIR repository behind vulnerability scanning before any production push — OCIR supports it natively and it costs you nothing but a few extra seconds per push.

The complete working project from this tutorial consists of five files: a Dockerfile for your game server image, fleet.yaml defining your warm pool, fleetautoscaler.yaml controlling scale-up and scale-down behavior, allocation.yaml as a manual test harness for claiming a server, and the OpenTelemetry Collector Helm values file for metrics export. Together with the oci ce cluster create command from Step 3 and the Helm install from Step 7, that’s everything needed to go from an empty OCI tenancy to a horizontally autoscaling, observable, dedicated-game-server backend running on Kubernetes 1.36.4 and Agones 1.60.0. If you’re already running similar fleets on Agones on a generic Kubernetes cluster, migrating these manifests across is mostly a matter of swapping node selectors and your container registry path — the Fleet, FleetAutoscaler, and GameServerAllocation specs themselves are cloud-agnostic by design.

For comparison against other managed game server options, see how this setup stacks up against Amazon GameLift’s managed server fleets, Nakama’s self-hosted game server stack, and Fly.io Machines for ephemeral game server instances. If your backend also needs a persistent leaderboard or player progression store, Cloud Spanner’s globally consistent leaderboard setup pairs well with an Agones-based server fleet, and a matchmaking layer built on Open Match 2 can sit in front of the allocator service described in Step 11. For broader context on running production workloads across providers, see our cloud computing coverage.

Frequently Asked Questions

Is Oracle Cloud’s OKE actually free to run a game server cluster on?
The Basic Cluster control plane is free indefinitely. Worker node compute, storage beyond 200 GB, and data transfer beyond 10 TB per month are billed at standard rates once you exceed Always Free quotas, which as of June 2026 cap Ampere A1 Flex at 2 OCPUs and 12 GB total.

Does Agones officially support Oracle Cloud, or is this an unsupported workaround?
Agones’ official documentation includes a dedicated OKE cluster-creation guide alongside its GKE, EKS, AKS, and Minikube guides, so this is a documented, supported installation path rather than an unofficial hack.

What Kubernetes version should I use on OKE right now?
1.36.4 is the newest version OKE supports as of its October 1, 2026 release notes, alongside 1.35.2 and 1.34.10. Use the newest supported version unless you have a specific compatibility reason not to.

How does OKE pricing compare to EKS or GKE for a small game server cluster?
OKE’s Basic Cluster tier has no control-plane fee at all. EKS charges $0.10 per cluster-hour for standard support, rising to $0.60 once a Kubernetes version moves into extended support. GKE charges a flat $0.10 per cluster-hour offset by a non-rolling $74.40 monthly credit. Worker node costs are comparable in structure across all three.

Can I use this setup for a production multiplayer game, not just testing?
Yes, but the Basic Cluster tier lacks an SLA and the Always Free compute allowance is too small for serious concurrent player load. Move to an Enhanced cluster and paid Compute capacity, and add a Network Load Balancer rather than relying on the bandwidth-capped Always Free Flexible Load Balancer.

What’s the latest stable Agones version I should install?
Agones 1.60.0, released September 22, 2026, is the current stable release at the time of this guide. Check the Agones GitHub releases page for anything newer before you install.

Do I need a separate load balancer for every game server pod?
No. Agones assigns each pod a dynamic host port, and clients connect directly to the node’s address and that port. A load balancer is typically only needed in front of the allocator API or a matchmaking HTTP endpoint, not in front of every individual game server.

Why did my node pool stop scaling after I added more nodes?
This usually means you’ve exceeded your Always Free Ampere A1 quota of 2 OCPUs and 12 GB total. OCI won’t provision additional Always Free capacity beyond that ceiling; you’ll need to either shrink your node shapes or attach a billing method to provision paid Compute capacity.

Should I run a separate OKE cluster per region for a global game?
Generally yes, once you have players spread across continents. A single regional cluster adds unavoidable round-trip latency for anyone far from it, and Agones’ Fleet and FleetAutoscaler resources are designed to be duplicated per region rather than stretched across one. Because OKE’s Basic Cluster tier carries no control-plane fee, running a second or third regional cluster purely for latency coverage doesn’t multiply your control-plane costs the way it would on a provider charging per cluster-hour with no free tier.