System:
Debian 13 KDE (actually MX Linux, but doesn't seem to matter)
Wayland (xwayland installed as well)
Docker 29.5.2
Dockerfile:
FROM debian:trixie
ENV DEBIAN_FRONTEND=noninteractive
ENV LANG=en_US.UTF-8
ENV LANGUAGE=en_US:en
ENV LC_ALL=en_US.UTF-8
# Set locale
RUN apt-get update && apt-get install -y --no-install-recommends \
locales && \
apt-get clean && \
sed -i '/en_US.UTF-8/s/^# //g' /etc/locale.gen && \
locale-gen
# Install Wayland-specific packages
RUN apt-get update && apt-get install -y --no-install-recommends \
dbus \
libwayland-client0 \
libwayland-egl1 && \
apt-get clean
# Install X-specific packages
RUN apt-get update && apt-get install -y --no-install-recommends \
dbus-x11 && \
apt-get clean
# Add contrib, default is only main
RUN sed -i 's/^Components:.*/Components: main contrib/g' /etc/apt/sources.list.d/debian.sources
# Add 32-bit arch for Steam libraries
RUN dpkg --add-architecture i386
# Install Steam
RUN apt-get update && apt-get install -y --no-install-recommends \
steam-installer \
pciutils && \
apt-get clean
# Additional
# TODO: What is really needed?
RUN apt-get update && apt-get install -y --no-install-recommends \
vulkan-tools \
mesa-utils \
x11-xserver-utils \
libvulkan1 \
mesa-vulkan-drivers && \
apt-get clean
# TODO: Does `-storebeta` even work?
# https://developer.valvesoftware.com/wiki/Command_line_options_(Steam)
CMD ["/usr/games/steam", "-storebeta"]
To run the container:
xhost +
sudo docker run -it --name steam \
-e XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR \
-e WAYLAND_DISPLAY=$WAYLAND_DISPLAY \
-v $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY:$XDG_RUNTIME_DIR/$WAYLAND_DISPLAY \
-e DISPLAY=$DISPLAY \
-v /tmp/.X11-unix:/tmp/.X11-unix \
--privileged steam:trixie
(The --privileged part is only temporary until I found out which capabilities are actually needed. Please don’t run your containers with --privileged.)
I get the GUI dialogs to download Steam just fine, so at least some display forwarding is working:

The installation works fine, but when starting Steam it seems like it’s not able to find Vulkan devices and then doesn’t open any Steam window. (The container is not stopping and I’m seeing repeated ./steamwebhelper output after this.)
[...]
Running query: 1 - GpuTopology
CVulkanTopology: failed create vulkan instance: -9
CVulkanTopology: failed to create vulkan instanceFailed to query vulkan gpu topology
Failed to query vulkan gpu topology
Response:
Exit code: -2
[...]
Vulkan missing requested extension 'VK_KHR_surface'.
Vulkan missing requested extension 'VK_KHR_xlib_surface'.
BInit - Unable to initialize Vulkan!
[...]
However, Vulkan is clearly working fine in the container, as this commands displays the cube rendering just fine:
$ sudo docker exec -it steam vkcube
Selected WSI platform: xcb
Selected GPU 0: AMD Radeon RX 550 / 550 Series (RADV POLARIS12), type: DiscreteGpu
(I’ve also tried it on another (pure) Debian machine with a 2080Ti, but I’ve got the same issue.)
I’ve created other GUI containers in the past (Firefox for example) and didn’t have these problems.
Does anybody have an idea and can point me in the right direction?
The first thing is why Docker, when Podman exists and it’s way better?
Because that’s not what OP asked.
What I’m trying to do is just question the OP about that
I’ll level with you, it comes off as oblivious with a touch of arrogance. Its the same energy in the Mac vs windows arguments. What would help would be explaining why you believe podman would be a better solution to OPs problem.
What am I doing wrong?
Putting Steam in a container. Did you even consider the pressure buildup?
Yea, where is your relief Valve?
But why?
Yes OP, why
Proprietary software bad.
Proprietary software in containment not so bad.What specifically are you concerned about? There are easier ways to prevent or limit system resource access.
Wouldn’t it be a bit easier to use the Flatpak?
The entire point of Flatpak is to run Linux Software in a container.
In case you haven’t noted, this isn’t about ease of use. (Also Steam isn’t verified on Flathub and I only use verified apps.)
Flatpak doesn’t have digital signatures anyway, so effectively nothing is verified on Flathub
Then create your own Flatpak or use Bubblewrap (that’s what Flatpak uses under the hood). Along with OpenSnitch and some good DNS (I particularily recommend HaGeZi’s server, and hBlock for hosts-level blocking) it should be (sufficiently) good.
I’d maybe check out steam-headless container and check that out
Use distrobox. https://www.mulle-kybernetik.com/weblog/2023/steam_in_distrobox.html or similar steps
Adjust distrobox’s sandboxing from the working setup it will give you to something more secure, since it gives access to the entire home directory and other stuff you might not want.
Or just read distrobox configs and copy what you need to docker.
Distrobox basically has no isolation at all. Giving it another home directory doesn’t restrict access to the real home directory. Other directories are also not restricted (/media, /mnt, /var/log).
--unshare-alldoesn’t change anything about that fact.Thankfully distrobox is just an open source wrapper around podman/docker, so you can make it more isolated if you want.
AFAIK no such configuration options exist for distrobox. It’s intentionally designed to not offer any isolation.
You can just then manually edit its configuration files.
Or use Bwrap along with that.
Or just read distrobox configs and copy what you need to docker.
I can’t assist you but I’m intrigued about the process. Can’t see any particularly helpful ideas here, you’d probably have better success at the docker forums, they’re pretty good.
Running Steam in a docker container.
It sounds like a hypervisor setup would be a better approach for your use case.
Then I have to pass my GPU to the VM exclusively. There are also memory latency problems. Plus I have to reserve ressources from my host system. I’ve been a user of VFIO setups in the past.
What am I doing wrong?
I think it’s possible you have few misconceptions of things. There are only negatives.
Lolwut
Oh boy. While I would recommend using flatpak or bwrap if you want a sandbox, my guess is you probably need to give the container access to the devices in /dev, like:
--device /dev/dri/:/dev/dri/or
--device /dev/dri/renderD128:/dev/dri/renderD128You might also need to make sure the user inside the container actually has access to that device.
I’d suggest looking at Jellyfin’s Hardware Acceleration Docs since it goes into detail on getting hardware acceleration working within docker.






