Spotify in Docker Container

I like keeping my system clean. Too many installed packages, too many dependencies I’ll never use again – that kind of thing bugs me. So when I realized I could run Spotify inside a Docker container instead of installing it natively, I gave it a shot.

Turns out it works, and it taught me a few things about how Linux handles graphical applications. Let me walk you through it.

Why Bother with Docker for a Desktop App?

Fair question. For me, it comes down to two things: I don’t want to litter my host OS with dependencies, and I want the ability to nuke an application’s entire environment without hunting down config files scattered across my filesystem.

Docker gives me that isolation. If I wipe my machine or switch distros, my containerized apps are just a docker run away from working again.

The Problem: Docker Has No Screen

Here’s the catch. Docker containers don’t have a display server. They’re headless by default – no GUI, no windows, no nothing. To run a graphical app like Spotify inside a container, you have to share the host’s display with it.

This involves two concepts worth understanding:

1. X11 – the display server protocol that Linux has used for decades (Wayland is the newer alternative, but X11 is still widespread)
2. The DISPLAY environment variable – how X11 clients know where to send their windows

Running Graphical Application on Docker

The DISPLAY Variable

Every X11 client reads the DISPLAY environment variable to figure out which display server to talk to. The format is:

hostname:N.D

Where:

• hostname is the machine running the X server. If you leave it blank, it means localhost.
• N is the display number (usually 0). A machine can have multiple displays.
• D is the screen number. Almost always 0.

When you’re sitting at your Linux desktop, echo $DISPLAY will probably return :0.0 or just :0. That’s the X server running on your local machine.

What X11 Actually Does

The X Window System uses a client-server model, but it’s the reverse of what you might expect. The X server runs on the machine with the physical display (your laptop, your desktop). Applications are X clients – they connect to the server and ask it to draw windows, handle keyboard input, and so on.

This separation means the application doesn’t need to know anything about your hardware. It just talks to the X server, and the X server handles the rest.

Now that we understand the theory, let’s get Spotify running in a container.

The Dockerfile

Here’s a Dockerfile that builds a Spotify image. I’ve updated it from the original to use a current Ubuntu base and the latest Spotify repository signing key:

FROM ubuntu:22.04
LABEL maintainer "Cleber Rodrigues"
RUN apt-get update && apt-get install -y \
    dirmngr \
    gnupg \
    curl \
    ca-certificates \
    --no-install-recommends \
    && apt-get update && apt-get install -y \
    apulse \
    libasound2 \
    libgl1-mesa-dri \
    libgl1-mesa-glx \
    libpulse0 \
    sudo \
    --no-install-recommends
RUN curl -sS https://download.spotify.com/debian/pubkey_5384CE82BA52C83A.asc | sudo gpg --dearmor --yes -o /etc/apt/trusted.gpg.d/spotify.gpg
RUN echo "deb https://repository.spotify.com stable non-free" | sudo tee /etc/apt/sources.list.d/spotify.list
RUN sudo apt-get update && sudo apt-get -y install spotify-client && rm -rf /var/lib/apt/lists/*
ENV LANG en-US
COPY local.conf /etc/fonts/local.conf
COPY entrypoint.sh /usr/bin/startspotify
ENTRYPOINT [ "startspotify" ]

A few notes on what changed from older versions you might see floating around:

• Ubuntu 22.04 instead of 18.04 (which reached end-of-life in May 2023)
• pubkey_5384CE82BA52C83A.asc instead of the old pubkey.gpg – Spotify rotated their signing key
• https:// for the repository URL instead of http://
• gpg --dearmor instead of the deprecated apt-key add

If you don’t want to build it yourself, I have a pre-built image on Docker Hub:

docker pull bitslovers/spotify:v1

Running Spotify with x11docker

You can share the X11 socket manually with docker run -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix, but that approach has security issues – it gives the container broad access to your X server.

x11docker is a better option. It handles display forwarding properly by spinning up a separate X server for the container, which keeps things isolated. It also supports Wayland, PulseAudio, PipeWire, and GPU acceleration.

Installing x11docker

On Debian, Ubuntu, or Linux Mint:

sudo apt-get update
sudo apt-get -y install xpra xserver-xephyr xinit xauth xclip x11-xserver-utils x11-utils

Then install x11docker itself:

# Using sudo
curl -fsSL https://raw.githubusercontent.com/mviereck/x11docker/master/x11docker | sudo bash -s -- --update

Or if you’re running as root:

curl -fsSL https://raw.githubusercontent.com/mviereck/x11docker/master/x11docker | bash -s -- --update

x11docker runs on Linux and (with limitations) on Windows via WSL. It does not run on macOS.

Launching Spotify

x11docker --home=/data/spotify --pulseaudio --gpu -- --hostname=spotify bitslovers/spotify:v1

What the flags do:

• --home=/data/spotify – Persists Spotify’s data (cache, login session, downloaded music) at /data/spotify on the host. Without this, you’d have to log in every time you start the container.
• --pulseaudio – Routes audio from the container to the host via PulseAudio. If your system uses PipeWire, x11docker supports --pipewire as well.
• --gpu – Passes through GPU hardware acceleration for OpenGL rendering. Makes the UI smoother.

Quick Launch with a Shell Alias

I got tired of typing that long command, so I added an alias to my ~/.bashrc:

alias dspotify='x11docker --home=/data/spotify --pulseaudio --gpu -- --hostname=spotify bitslovers/spotify:v1'

Now I just type dspotify and I’m listening to music.

Other Options Worth Knowing About

Docker isn’t the only way to isolate Spotify on Linux. Depending on what you’re after:

• Snap: snap install spotify – This is Spotify’s officially supported Linux distribution method. It’s sandboxed, easy to update, and works out of the box on Ubuntu.
• Flatpak: flatpak install flathub com.spotify.Client – Community-maintained. Works well on non-Ubuntu distros.
• Distrobox: If you want the Docker-like isolation with less manual setup, distrobox handles X11/Wayland forwarding automatically.

The Docker approach in this post is still useful if you want full control over the container environment, or if you’re applying the same pattern to other GUI applications.

Wrapping Up

The real takeaway here isn’t about Spotify specifically. It’s that running any GUI application in a Docker container is possible once you understand how X11 (or Wayland) display forwarding works.

I’ve used this same pattern to containerize browsers, IDEs, and other desktop tools. It keeps my host system clean, and it gives me reproducible environments that I can version and share.

If you found this useful, check out some of our other posts:

Maven and Node.js

What is AWS KMS?