Skip to main content

Port policies

When starting a payload, the IMS zeuz system is assigning it ports that game clients can use to connect to it. These port are defined as part of the Allocation settings.

Port policies

Each port on a payload requires a port policy to be selected. This policy determines how internal and external ports are assigned and mapped.

There are two types of policies: dynamic and passthrough.


The dynamic port policy is the default and should cover most use cases. The dynamic policy allows your game server to always listen on a static port, which gets mapped to a unique port on the host machine. Clients can then connect to that host machine port, while the traffic gets routed to the static port on the payload.

For example: if you are listening for game client connection on port 7777 and listen for Steam connections on port 1234 you would configure your allocation like so:

Allocation dynamic ports settings

When starting a payload you will then see that the system started the payload on a machine, exposing its IP address along with the mapped port numbers available for incoming connections:

Ports mapped in console

Effectively, the mapping results into this:

Dynamic port policy


The passthrough port policy is only required if you have specific networking needs, if your game requires clients to connect to the same port number that the server listens on. When using passthrough, you can not set which port will be used, instead, the system will find an available port on the machine and open the connection to the same port number in your game container.


You don't get to choose the port number in *passthrough mode as the system assigns the ports to each payload.


We recommend using the dynamic port policy for most workloads. If you are considering using passthrough in order to know the machine-mapped external port, please refer to Know what ports are assigned to your game server below.

Allocation passthrough ports settings

For the game client, nothing changes. However, the game server must request the GetPayload endpoint of the Payload Local API in order to know what ports it should bind to.

Passthrough port policy

Port protocol

There are three protocol options for a port:

  • UDP
    • Opens the port for UDP traffic
  • TCP
    • Opens the port for TCP traffic
    • Opens a port number for both UDP and TCP traffic. Two ports will show up in the payload status, one for each protocol: $name-udp and $name-tcp, where $name is the name given to the port in the allocation port specification.

Know what ports are assigned to your game server

In most cases, your game server does not need to know what machine ports it is mapped to.

When making a reservation request on an allocation, your backend (or matchmaker) will receive the machine ports exposed to the world for players to connect to.

In certain cases, you may need to know what port the system has assigned on the machine to your game server.

For example:

  • When using the passthrough port policy the payload will need to know the ports it has been assigned so that your game server can bind itself to them.
  • When your game server needs to advertise its ports to other services.

This is achieved by requesting the payload details in the Payload Local API from within the Game Server. The response contains the ports mapping (in result.status.ports) by name. It always contains the external port mapping, regardless of your selected port policy.