Shamelessly copying the following note from https://github.com/dmadisetti/steam-tui/blob/main/README.md:

So until further notice, this project is deprecated. I won't support requiring multiple gigabytes worth of packages (GUI stuff mostly, totalling to about ~ 4.5 last time I checked) just to run steamcmd.

The project will be archived for the time being to stop GitHub from triggering CI workflows.

This notice will be removed as soon as Valve has a backend only mode again, or someone finds a way how we can run steamcmd without these pointless dependencies.

This project aims to provide pre-packaged SteamCMD docker images which are up-to-date and especially easy to use.

• Differences to official images
  • tmux session socket
  • console input socket
  • Base image
  • SSH server
• HLDS image
  • HLDS-based game servers
• SRCDS image
  • SRCDS-based game servers
• Source 2 image
  • Source 2 based game servers
• Running multiple game servers
• Kubernetes
• Image repositories
• Known bugs
• How to contribute?

While the official images are fine, my take differs in a couple ways:

These containers create a tmux session socket at /tmp/steamcmd/session.sock. If it is exposed to your local file system, you can use it to for example attach to the SteamCMD game server session:

tmux -S </path/to/bind-mounted/socket> attach

To expose the socket, just bind-mount the path (using cs2 as an example):

services:
  cs2:
    ...
    volumes:
      - /tmp/steamcmd:/tmp/steamcmd
    ...

Which would translate to:

tmux -S /tmp/steamcmd/tmux.sock attach

Beware that attach is a tmux command! So you could also use a instead:

tmux -S /tmp/steamcmd/tmux.sock a

Instead of the attach command, you can use send-keys to execute a command directly within the game server's shell, say bot kick:

tmux -S /tmp/steamcmd/tmux.sock send-keys "bot_kick" "Enter"

Unfortunately there's no way currently to provide a shorthand for send-keys yet.

To get around the tmux session syntax noise, I decided to create a Unix domain socket as well.

To type something in the SteamCMD game server console directly, you can use netcat-openbsd / openbsd-netcat like this:

echo "my server command" | nc -UN /tmp/steamcmd/console.sock

To expose the socket, just bind-mount the path (using cs2 as an example):

services:
  cs2:
    ...
    volumes:
      - /tmp/steamcmd:/tmp/steamcmd
    ...

This socket makes it possible to forward console inputs from a web API or secure TCP socket for example.

• Based on the official SteamRT v3 "(Sniper)" image with all necessary dependencies and basic tools preinstalled
• For legacy game servers (Source 1, non-CS 2 and HLDS) SteamRT v2 "Soldier" is used instead
• The SteamCMD runtime error [S_API FAIL] SteamAPI_Init() failed; unable to locate a running instance of Steam, or a local steamclient.dll. is fixed
• It does not operate under the root user - a steamcmd user with default UID and GID of 5000 each is used instead
• The server path is changed to /var/lib/steamcmd/server
• openssh-server is installed to provide an easy and secure way of managing server files externally, even when using Kubernetes

See the SSHD configuration at image/base/etc/ssh/sshd_config.d/steamcmd.conf for the options applied to the server. Only public key authentication is enabled!

To enable the SSH server, set the environment variables STEAMCMD_SSH_SERVER_ENABLE to 1 and STEAMCMD_SSH_AUTHORIZED_KEYS to the Base64 encoded public SSH keys separated by newlines (see compose/hlds/cs-ssh.yml or compose/srcds/css-ssh.yml). STEAMCMD_SSH_AUTHORIZED_KEYS essentially represents the ~/.ssh/authorized_keys file on the server side in encoded format.

Base64-encode your public SSH keys:

cat <ssh-key1>.pub <ssh-key2>.pub <ssh-keyN>.pub | base64 -w 0

Then use the output as the value for STEAMCMD_SSH_AUTHORIZED_KEYS.

• Based on the base image
• Provides a generic base for HLDS-based game servers
• Provides the script server.sh (HLDS) to manage game servers using a single tmux session
• Provides a docker-entrypoint.sh which itself is executed as root with always-correct timezone and ownership of server files

The server.sh checks for the user executing it. If it's root, it executes itself as the steamcmd user via exec gosu to prevent ownership mismatch.

• Composed via compose/hlds
• Game server specific environment variables are used for configuration

Currently supported game server images:

Note: Ricochet seems like it's not available anymore.

• Based on the base image
• Provides a generic base for SRCDS-based game servers
• libstdc++, libtinfo and other runtime errors due to missing dependencies are fixed
• Provides the script server.sh (SRCDS) to manage game servers using a single tmux session
• Provides a docker-entrypoint.sh which itself is executed as root with always-correct timezone and ownership of server files
• Tries to enable 128 tick configurations by default. CS:S will default to 67 because Valve said it's better this way (in 2010).

The server.sh checks for the user executing it. If it's root, it executes itself as the steamcmd user via exec gosu to prevent ownership mismatch.

• Composed via compose/srcds
• Game server specific environment variables are used for configuration

Currently supported game server images:

• Based on the base image
• Provides a generic base for Source 2 based game servers
• libstdc++, libtinfo and other runtime errors due to missing dependencies are fixed
• Provides the script server.sh (SRCDS) to manage game servers using a single tmux session
• Provides a docker-entrypoint.sh which itself is executed as root with always-correct timezone and ownership of server files
• Tries to enable 128 tick configurations by default (Black Mesa: Deathmatch).

The server.sh checks for the user executing it. If it's root, it executes itself as the steamcmd user via exec gosu to prevent ownership mismatch.

• Composed via compose/source2
• Game server specific environment variables are used for configuration

Currently supported game server images:

Note that Black Mesa: Deathmatch is built on the Counter-Strike: Global Offensive engine, which is a modified/updated version of Source 1. However, since the Source 2 image is based on the SteamRT sniper runtime, which was also used for CS:GO before CS 2 came along, the Black Mesa: Deathmatch game server container is now run via the Source 2 image. If you encounter any issues, please head over to the project issues and create a new issue to let me know.

If you want to run multiple game servers using one single compose file, see the example file compose/srcds/multiple.yml.

See https://github.com/thetredev/helm-charts.

The main image repository is: ghcr.io/thetredev/steamcmd
See https://github.com/thetredev/steamcmd/pkgs/container/steamcmd/versions for details.

The GitHub image repository is synchronized with the Docker Hub repository:
https://hub.docker.com/r/thetredev/steamcmd

The GitHub Actions workflows are setup in the following way:

• Pushes to the main branch lead to the image tags ghcr.io/thetredev/steamcmd:<image>-latest, where <image> is one of the following: base, hlds or srcds (see the supported game server images above)
• Pushes of tags lead to retagging the ghcr.io/thetredev/steamcmd:<image>-latest images to ghcr.io/thetredev/steamcmd:<image>-<tag>

All image builds used to be scanned for CVEs and only pushed as latest or the given tag if no CVEs are found. These scans have been removed and/or disabled since we're relying on official Steam Runtime images now (commit a64d5003ac8d84eccc6326bc8270eef1105745e0) and we simply trust Valve to make the base images as secure as possible.

See the project issues.

Just throw me a pull request - feel free to hack along!