Autoscaling

projects/{project}/locations/{location}/gameServerGroups/{group}

The shape a minigame needs and a single server cannot be: a lobby fills and more servers arrive, a round ends and they go away. You declare a game, a size range and what to scale on; the group creates and removes servers to match.

Autoscaling → New group → choose a game, a machine type and a size range → Create group

Members are ordinary game servers

A member is a game server with group set, and everything that works on a server works on it — read it, read its logs, see who is playing on it.

Everything about a member — the game, the build, the machine type, whether it runs on spot, whether it keeps data, whether players can reach it, which private network it joins — is declared once on the group, so members never differ from one another.

The group itself is free

You pay for its members, billed exactly as any other game server, and for its schematic, billed as storage. The group costs nothing.

Warm-up

A group's first act is to create one server, let it install and generate its world for warmup_duration, capture it as a schematic, and remove it. Every member then starts from that capture — seconds rather than minutes.

The warm-up server is not charged for. It exists so your own members do not each repeat the same install.

If a capture fails, the group still scales; its members simply start from scratch, more slowly. To reuse a schematic you already have, set schematic when creating the group — see Giving one to a group.

Scaling policy

Every term is a number to hold, not a threshold to cross.

The terms combine by maximum: each answers "how many members does this load need", and the largest answer is taken.

min_size: 0 is legitimate, and is what a group for an off-peak game wants: no players, no servers, no bill. The first player then waits for a member to start, which is what the schematic is for.

The CLI sets --min-size, --max-size, --target-player-percent, --min-free-slots, --scale-on-waiting and --scale-in-patience; Terraform the same, as min_free_player_slots and scale_on_waiting_connections. The other terms are set through the API.

Every brake points inward

Scaling out late is a queue. Scaling in early is a disconnection, and only the first is fixed by waiting. So a group:

A member whose players Plany could not read is never a candidate for removal. scale_in_patience exists because player counts come from your game's own output, which can lag — a server between two rounds reads as empty for a few seconds.

Draining, not disconnecting

Scale-in drains. A draining member keeps the players it has, and is removed once it is empty or past drain_timeout. The deadline is what makes it finish — somebody who never leaves would otherwise hold a member forever — so make it long enough for a match to end inside it. When the group needs to grow again, it brings a draining member back before creating a new one.

For an ephemeral group (ephemeral: true, set through the API) a removed member is deleted; for any other group it is stopped, keeps its world, and is started again when the group grows.

Sleeping members

sleep_after_idle on a group is given to every member: a member with nobody on it for that long goes to sleep, keeps its world and costs nothing to run, exactly as a single server does. A sleeping member still counts toward the group's size, and a player connecting to it — or an allocation — wakes it. It is set through the API, and refused on an ephemeral group.

Rolling out a new build

A group's build is fixed when it is created, so a new version of the game's build does not reach the fleet by itself — two versions in one fleet would match players across them. Change the group's build to move it:

1resource "plany_playpute_game_server_group" "prop_hunt" {
2  group_id = "prop-hunt"
3  game     = "games/garrys-mod"
4  build    = plany_game_build.v2.name
5  max_size = 8
6}

The group keeps creating members on the old build while it warms up a schematic of the new one (pending_build shows which). Once that lands it replaces outdated members within rollout — at most max_surge extra members and max_unavailable missing ones, 25% each unless you set them — and never replaces a member the game has marked allocated: a match finishes on the build it started on. outdated_size counts the members still to go. The build has to be READY.

Allocation

Every Playpute server can use the Agones SDK, and a group can be used the way an Agones fleet is. A game calls Ready() when it can take a match; AllocateGameServer picks a ready server, marks it allocated, writes your labels onto it and returns its addresses — waking it first if it was asleep. Two callers never get the same server, and a server you stopped yourself is never allocated.

1grpcurl -H "authorization: Bearer $PLANY_API_KEY" \
2  -d '{"parent": "projects/my-game/locations/eu-west-2",
3       "labels": {"match": "m-812"}}' \
4  api.plany.cloud:443 plany.playpute.v1.PlayputeService/AllocateGameServer

selectors narrow the choice by the labels on each member — member_labels on the group sets them. With buffer_size or buffer_percent in the policy, the group keeps that many members ready on top of the allocated ones, and an allocated member is never scaled in. ready_size, allocated_size and sleeping_size on the group report the counts.

Exposure

EXPOSURE_PROJECT_INTERNAL is the right choice for a fleet behind a matchmaker or lobby that dials members from inside the project: members get no public address and nothing a player can find. Choose EXPOSURE_PUBLIC, the default, if players pick a server from a list. In Terraform this is exposure = "PROJECT_INTERNAL".

States

Pause and resume with plany playpute groups update my-fleet --paused (and --paused=false), or paused in Terraform.

state_message says why the group is where it is — including, when it is holding steady, why it is not scaling. current_size is how many members exist and desired_size how many the group last decided there should be.

Quota

playpute.plany.cloud/game_server_groups is deliberately low: 2 on Hobby, 25 on Pro. A group creates servers without anybody clicking anything, so what this limits is how many independent fleets can be doing that. Members count against the ordinary server quotas — instances, vcpus, memory_bytes. See Quotas.