Steamworks Documentation
Steam Datagram Relay
Steam Datagram Relay (SDR) is Valve's virtual private gaming network. Using our APIs, you can not only carry your game traffic over the Valve backbone that is dedicated for game content, you also gain access to our network of relays. Relaying the traffic protects your servers and players from DoS attack, because IP addresses are never revealed. All traffic you receive is authenticated, encrypted, and rate-limited. Furthermore, for a surprisingly high number of players, we can also find a faster route through our network, which actually improves player ping times.

This relay network can be used for both peer-to-peer traffic and dedicated servers. In both cases, you will need to use the ISteamNetworkingSockets interface.

This is a cross platform service A Networking API and DDoS solution for a cross-platform game is useless if it only works on one platform. As long as you ship your game on Steam and meet some other reasonable requirements, you can access the Steam Datagram Relay for players on other platforms or stores! Please contact us for the relevant SDKs and to talk about the fine print. And if you don't ship on Steam, feel free to use the opensource version of the API for whatever you want.

For peer-to-peer traffic, all you need to do to take advantage of SDR is to use APIs such as ISteamNetworkingSockets::CreateListenSocketP2P and ISteamNetworkingSockets::ConnectP2P. Steam will take care of everything else.

The remainder of this document applies to dedicated servers.

General Requirements for Dedicated Servers

In order to run dedicated servers behind SDR, you'll need to do the following:
  • Any place where clients see the IP address of your server will need to be changed to use a different identifier instead, probably the server SteamID.
  • Your server will still need a public IP, so that it can receive traffic from relays. However, this IP can be dynamic, and it will never be revealed to players. (NOTE: At this time, only IPv4 is supported, but IPv6 support is planned.)
  • You'll need to modify your networking code to use ISteamNetworkingSockets for connectivity. (Note that this API also supports plain UDP transport, which is very useful for testing. Also, there's an opensource version.)
  • You'll need some way for players to learn the SteamID of your server. Note specifically that the ISteamMatchmaking and ISteamGameserver APIs use public IP to refer to dedicated gameservers, and cannot be used for this purpose. It's OK to use lobbies, so long as the server IP is never revealed to players.

The peer-to-peer APIs work just fine even when one "peer" is a dedicated server! But there's one important catch: if your dedicated server is not near one of the data centers where we are running relays, then the relayed route might be slower than the ordinary IP route that players would get using plain UDP connectivity. (You will normally not enable NAT punch for dedicated servers, since that reveals the IP address of the server and opens it up to DDoS attack.)

Dedicated Servers in Known Data Centers

For the optimal dedicated server experience, the server should be run in a known data center that is part of the SDR network, where we make sure that relays are running nearby and the relayed route is never slower than the "direct" route. Servers running in these known data centers connect using a special API. This use case is referred to in the SDK as "Hosted Dedicated Server". Note that this doesn't mean that Valve is hosting the servers, only that they are hosted in a data center that is known to the Steam Datagram Relay system. At this time, we are only supporting the major cloud and gameserver providers such as Amazon AWS, Microsoft Azure, and Google Cloud. (As well as our own data centers -- see below.)

If you are running servers in a major provider and want us to run relays near your servers so that you can take advantage of SDR, please get in touch with us!

NOTE: Carrying this sort of traffic is a beta feature, and is not a Steamworks feature we can offer to all partners at this time. There may be technical or capacity issues that prevent us from offering it to all partners.

Simple Connection Flow to Dedicated Server Without Game Coordinator

If you don't have your own central matchmaking / login service (we sometimes call this the "game coordinator") that assigns players to servers, or just want to keep things as simple as possible, then you can connect to a dedicated server in a known data center using ISteamNetworkingSockets::CreateListenSocketP2P and ISteamNetworkingSockets::ConnectP2P. In this case, the connection begins on the client just like an ordinary P2P connection. Rendezvous messages are sent through Steam, so if the player or server loses their connection to Steam, the connection cannot be made. Also, Steam does not restrict who can attempt to connect, aside from verifying that the player is signed into Steam and owns the game.

Ticket-Based Server Connection Flow

If you do have your own game coordinator service, it is recommended to use a ticket-based connection flow. This is slightly more complicated, but it offers several advantages over using simple P2P-style connection calls. First, you only issue tickets to players who should be allowed to attempt to connect. Second, once a player has a ticket, they can connect to the server even if they lose connection to Steam, or their computer crashes. This can be very important for games with penalties for leaving the game.

A ticket-based connection to a dedicated server over SDR works like this:

Configurating servers in known data centers

This section documents some technical details involved in configuring servers.


SDR uses two authentication mechanisms:

  • Relay tickets are issued by your game coordinator and authorize a specific client to talk to a specific dedicated server for a period of time. Relay tickets are only used for the dedicated server use case.
  • Certificates are used in the traditional way to authenticate, and perform DH key exchange to establish an encrypted channel. Certificates are an end-to-end concept, and can be used in all forms of SteamNetworkingSockets communication, including direct UDP connectivity or P2P.

We use a proprietary public key infrastructure (PKI) to authenticate clients and servers. Players are issued individual, short-term certificates, tied to their specific player identity. Steam takes care of this. For gameservers, we typically use longer term certificates that authorize an entire data center for a particular AppID. You will issue those certificates.

Before you can issue tickets and certificates, you'll need to generate a keypair and send us your public key. We will publish a certificate signed by our master CA key that marks your key as trusted for your app(s). Then, offline you will generate a certificate for each data center where you want to run servers, using our certificate tool, and sign it with your private key. You'll distribute those certificates to your gameservers over a secure channel, passing it to your server in the environment (see below).

You'll also use your key to generate tickets, each time a player connects to a gameserver.

Keep your CA private key and the private keys of your certificates safe! If your key leaks and needs to be revoked and replaced, it could lead to a disruption.

Environment variables

The dedicated server gets its configuration from environment variables. Note that in Valve data centers, all of these values will be set automatically for you.
  • SDR_LISTEN_PORT: The UDP port where your server will receive traffic from relays. The dedicated server only uses a single socket. (But you can have more than one logical "listen socket" by using "virtual ports". See ISteamNetworkingSockets::CreateHostedDedicatedServerListenSocket.) In our data centers, we typically use the 30xxx range.
  • SDR_IP: Your server must have a public IP that can receive "unsolicited" traffic from relays. If the server only has one interface with a public IP, then this will be used. Otherwise, you will need to tell the gameserver what IP to use. The SDR socket will be bound to INADDR_ANY, but this information is needed to fill out the server's SteamDatagramHostedAddress. Note in particular that this will usually need to be set in dev environments, where your server is behind a corporate firewall. (See below.) You can also specify a port, if the public port differs from SDR_LISTEN_PORT.
  • SDR_POPID: The 3- or 4-letter alphanumeric code (SteamNetworkingPOPID) of the data center, in production. In development environment, leave this blank.
  • SDR_PRIVATE_KEY: The private key from your certificate. It's an OpenSSH PEM block that begins with "-----BEGIN OPENSSH PRIVATE KEY-----".
  • SDR_CERT: Your signed certificate. It's a proprietary format PEM-like block that begins with "-----BEGIN STEAMDATAGRAM CERT-----".
  • SDR_NETWORK_CONFIG: Full path to a local, recent copy of the SDR network configuration file for your app. If this variable is not set, then to obtain the network configuration the server will fetch the copy using HTTP at boot time. For optimal performance you can periodically (e.g. once an hour) download the latest configuration and save it locally, so that a network hiccup doesn't cause any disruption. This is how Valve servers are configured.

Running in a dev environment

Because ISteamNetworkingSockets supports plain UDP connectivity, it's usually best to start by getting your code working through this interface over UDP, without worrying about relays.

We suggest that your server code use the presence of the SDR_LISTEN_PORT environment variable to decide whether your server should listen for SDR. You can use ISteamNetworkingSockets::GetHostedDedicatedServerPort to fetch the value.

In development, you will leave SDR_POPID blank. When SDR_LISTEN_PORT and SDR_POPID is blank, the POPID is set to the special 3-character code "dev".

In general, authentication is disabled for servers in the "dev" environment. (Clients and relays will both allow connections to "dev" servers without a signed cert, as long as they have a signed ticket.) You will need another mechanism to authenticate with your game coordinator. And your game coordinator needs to be careful when it issues tickets to any servers claiming to be in "dev"!

Your server needs to be able to receive unsolicited public traffic, which means that if it doesn't have a public IP, you'll need to setup a port forward in your firewall. And you'll probably need to set SDR_IP with the proper public IP (and port, if it differs from SDR_LISTEN_PORT).

Game Coordinator SDK

"Game Coordinator" is the term we use to refer to backend / matchmaking services. There is a separate, small SDK that you can link with your game coordinator which can be used to:
  • Issue tickets to give clients access to gameservers hosted behind SDR
  • Parse with PingLocation_t strings and calculate ping times between these objects
  • Take advantage of certain other advanced features.

The SDK is available here

Valve server hosting

Valve has a beta dedicated server hosting program. To participate, your game needs to meet the following requirements:
  • To protect our data centers, we require that all game traffic be routed through SDR and server IPs are never revealed. So you'll need to meet all of the requirements in the previous sections for relaying traffic over SDR.
  • You need to have servers hosted with another hosting provider. We can't be your only dedicated server provider. At this time we are primarily interested in helping developers reach more regions than they otherwise would be able to, or to expand capacity temporarily to meet some short term demand, such as a special event.
  • Your dedicated server needs to be a Linux docker image.
  • There are some other minor configuration and technical requirements, too. Get in touch with us and we can pass on those details.