Your Steam Deck Is a Linux PC: Non-Gaming Uses

June 3, 2026 21 min read Systems Administration

steam-decklinuxdistroboxsteamoshomelab

Contents

The Steam Deck shipped as a gaming handheld. What Valve quietly put inside it is an AMD Zen 2 APU running a full x86-64 Linux distribution — SteamOS 3, built on an Arch Linux base — with KDE Plasma sitting one mode-switch away. Every unit that has ever left a warehouse is a capable portable Linux workstation by default, no modifications required. The problem is that most owners never leave Game Mode, and the ones who do often collide immediately with SteamOS’s immutable root filesystem and conclude, wrongly, that the Deck is too locked down to be useful.

That conclusion is backwards. SteamOS 3’s immutability is a deliberate design, and once you understand its model — read-only root partition, A/B atomic updates, Flatpak for GUI apps, Distrobox for full development environments — the Deck becomes an impressively capable secondary Linux machine for a specific class of work. It is not a primary workstation replacement. Its thermals are constrained, its RAM is soldered and capped at 16 GB shared between CPU and GPU, and its form factor is at its worst sitting on a desk for eight hours. But as a portable dev terminal, a crash cart for your server rack, an emulation box, a media client, and a small Linux machine you can carry in a backpack, it is genuinely excellent — and it ships at a price point that makes dedicated portable Linux hardware look expensive.

The Hardware and What It Means

The original LCD Steam Deck carries an AMD APU (Aerith) with four Zen 2 cores at up to 3.5 GHz and an integrated RDNA 2 GPU with eight compute units. The OLED revision (released late 2023) uses a refined Aerith+ die with the same Zen 2 microarchitecture but higher clocks, better power efficiency, and a dramatically better display. Both models pair the APU with 16 GB of LPDDR5 in a unified memory architecture — the CPU and GPU share that pool. There is no discrete RAM slot; what you see is what you get.

Storage is an NVMe M.2 2230 drive, replaceable on both models. The LCD model shipped in 64 GB (eMMC), 256 GB, and 512 GB configurations; the OLED ships in 512 GB and 1 TB. A microSD slot provides relatively cheap capacity expansion, though latency and throughput are substantially worse than the internal drive.

Connectivity matters for non-gaming use: USB-C (with USB 3.2 Gen 2 and DisplayPort Alt Mode on the OLED; USB 3.1 Gen 1 and DisplayPort on the LCD), Bluetooth 5.0, and Wi-Fi 6E on the OLED (Wi-Fi 5 on LCD). There is no full-size USB-A port, no Ethernet jack, and no HDMI out — you need a dock for serious desktop use.

The critical point for anyone planning to use the Deck as a workstation: this is a real x86-64 processor. Every x86-64 Linux binary that compiles for Zen 2 runs on it. It is not ARM. You are not dealing with architecture translation, incompatible binaries, or an emulation layer for native software. When you open a terminal in Desktop Mode, you have a genuine Arch Linux environment on AMD x86-64 hardware.

Entering Desktop Mode and What You Find

From Game Mode, press the Steam button, navigate to Power, and select “Switch to Desktop.” The system drops you into a full KDE Plasma session. On the OLED in particular, the desktop environment is polished enough that the transition is not jarring — you are looking at a real KDE Plasma desktop with a taskbar, application launcher, Dolphin file manager, and Firefox pre-installed.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# From a Konsole terminal in Desktop Mode:
# Check what you're working with
uname -a
# Linux steamdeck 6.1.52-valve16-1-neptune #1 SMP ...  x86_64 GNU/Linux

cat /etc/os-release
# NAME="SteamOS"
# VERSION="3.6.x"
# ID=steamos
# ID_LIKE=arch

# The deck user has sudo access, but the root fs is read-only by default
# Verify this:
findmnt / | grep ro
# /  ...  ro,relatime

The Plasma session runs on Wayland with Xwayland for compatibility. The built-in controls (trackpads, gyro, face buttons) do not do anything useful in Desktop Mode by default — they function as a mouse and keyboard at a basic level, but you will want to attach a Bluetooth or USB keyboard and mouse for real productivity. The touchscreen works for tapping and scrolling.

The taskbar and application launcher give you access to the Discover app store, system settings, and any installed applications. On a fresh Deck, Firefox is available, Discover is present, and Konsole (the KDE terminal emulator) is accessible from the system tools section of the launcher. The system is functional as a Linux desktop immediately. The constraint you will hit within minutes is the read-only root filesystem.

The Immutable Base: SteamOS 3’s Architecture

SteamOS 3 is an immutable OS. This term is used loosely in the Linux ecosystem, but on SteamOS it means something specific: the root filesystem (/) is mounted read-only at boot, managed as a complete image, and replaced wholesale during updates rather than updated package-by-package. Valve delivers OS updates as signed image bundles via a tool called RAUC, which writes the new image to the inactive partition in an A/B pair, then reboots into it. If the new image fails, the bootloader falls back to the previous partition.

SteamOS 3 Filesystem Layering
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  ┌─────────────────────────────────────────┐
  │         Your Applications               │
  │  ┌──────────────┐  ┌─────────────────┐  │
  │  │   Flatpaks   │  │ Distrobox       │  │
  │  │  (~/.var,    │  │ containers      │  │
  │  │  /var/lib/   │  │ (~/.local/share/│  │
  │  │  flatpak/)   │  │  containers/)   │  │
  │  └──────────────┘  └─────────────────┘  │
  ├─────────────────────────────────────────┤
  │  Persistent User Layer   (/home/deck)   │
  │  (survives updates — your data lives    │
  │   here: ~/.config, ~/Documents, etc.)   │
  ├─────────────────────────────────────────┤
  │  Mutable Overlay   (/etc, /var)         │
  │  (partially persisted across updates    │
  │   via /etc/atomic-update.conf.d rules)  │
  ├─────────────────────────────────────────┤
  │  Read-Only Root Partition  (/)          │
  │  Arch-based SteamOS image, signed       │
  │  Replaced atomically on update via RAUC │
  │  A/B partition pair — fallback on fail  │
  └─────────────────────────────────────────┘
  ┌─────────────────────────────────────────┐
  │       EFI System Partition              │
  │  Stage-1 bootloader, partition selector │
  └─────────────────────────────────────────┘

The practical consequence: anything you install via pacman into /usr is gone after the next OS update. Packages you install to the system level are temporary, by design. SteamOS 3.6 introduced /etc/atomic-update.conf.d to allow specified configuration files to survive updates, but this applies to config files, not installed binaries.

The Four Ways to Install Software on SteamOS

Understanding this architecture makes the software installation story clear. There are four approaches, ranging from blessed to inadvisable:

Method	Survives Update	System Risk	Best For
Flatpak via Discover	Yes	None	GUI apps: browsers, media players, office, IDEs
Distrobox + Podman	Yes	None	Dev environments, CLI tools, package-manager workflows
`rwfus` (OverlayFS)	Fragile	Medium	Legacy workaround; avoid for new setups
`steamos-readonly disable` + pacman	No	High	Debugging only; temporary system-level changes

The Flatpak and Distrobox paths work with the immutable design. The other two fight against it.

Why You Should Not Just Disable the Read-Only Filesystem

steamos-readonly disable unlocks the root filesystem for writing and lets you run pacman -S like a normal Arch install. This works until the next OS update, which will overwrite everything you installed. More troublingly, a partial pacman -Syu on SteamOS will leave the system in an inconsistent state because SteamOS’s package database is not synchronized with upstream Arch — the package versions in the read-only image are not managed by pacman at all. Running pacman -Syyu has historically broken systems by mixing SteamOS’s patched packages with upstream Arch versions.

The rwfus project provides an OverlayFS layer over /usr that persists across reboots without disabling read-only mode, letting you use pacman without losing packages on reboot. It is more durable than a raw steamos-readonly disable, but its own documentation notes that when Valve updates a file that you have overlaid, OverlayFS will keep the old version, silently preventing the update from taking effect. This is a correctness and security risk on any long-lived installation.

For most use cases, neither approach is necessary. Flatpak covers GUI application needs. Distrobox covers development needs. The combination covers almost everything a secondary Linux machine would require.

Flatpak: The Blessed Application Layer

KDE Discover in Desktop Mode connects to Flathub by default. Adding applications is straightforward — open Discover, search, install. The Flatpak sandbox isolates applications from the read-only system while persisting application data in /var/lib/flatpak and per-user data in ~/.var/app.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# Install an application via CLI (Flatpak is already configured)
flatpak install flathub org.kde.okular       # PDF/e-reader
flatpak install flathub com.visualstudio.code # VS Code
flatpak install flathub com.obsproject.Studio  # OBS
flatpak install flathub io.github.celluloid_player # Video player
flatpak install flathub org.mozilla.firefox   # Firefox (pre-installed on some builds)

# Jellyfin Media Player — the best way to run a Jellyfin client on the Deck
flatpak install flathub com.github.iwalton3.jellyfin-media-player

# RetroDeck — entire retro emulation stack as a single Flatpak
flatpak install flathub net.retrodeck.retrodeck

# List installed Flatpaks
flatpak list --app

# Update all Flatpaks
flatpak update

Flatpak applications update independently of the OS. They are self-contained with their own runtimes. The trade-off is that some applications feel slightly heavier than native installs due to runtime bundling, and CLI tools packaged as Flatpaks are often awkward to use from a terminal because they run sandboxed. For terminal utilities and build toolchains, Distrobox is the right answer.

Distrobox: A Full Linux Userland Without Breaking Anything

Distrobox wraps Podman (or Docker) containers to create a seamlessly integrated Linux environment inside a mutable container on an otherwise immutable host. From SteamOS 3.5 onward, both Podman and a copy of Distrobox ship with the base OS in /usr/bin. However, since /usr/bin is on the read-only partition, the pre-installed versions may lag behind upstream. The recommended approach is to install the current version of Distrobox locally into your home directory.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# Install the latest Distrobox to ~/.local/bin (survives updates, lives in /home)
curl -s https://raw.githubusercontent.com/89luca89/distrobox/main/install | \
  sh -s -- --prefix ~/.local

# Ensure ~/.local/bin is in your PATH
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

# Verify
distrobox version

For Podman, SteamOS ships a system Podman binary, but it lives on the read-only partition. If you need a newer version than what SteamOS ships, the Distrobox project maintains an install-podman script that installs Podman locally to ~/.local:

1
2
3


# Only needed if you want a newer Podman than the SteamOS-bundled version
curl -s https://raw.githubusercontent.com/89luca89/distrobox/main/extras/install-podman | \
  sh -s -- --prefix ~/.local

Creating and Using Containers

Distrobox creates OCI containers but integrates them with the host in ways that feel native: your home directory is shared, your display session is passed through, audio works, and X/Wayland applications launched from inside the container appear on your desktop.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


# Create an Ubuntu 24.04 development container
distrobox create --name dev-ubuntu --image ubuntu:24.04

# Create an Arch container (full pacman, AUR access via yay)
distrobox create --name dev-arch --image archlinux:latest

# Enter the container — prompt changes, but you're in ~/
distrobox enter dev-ubuntu

# Inside the container: full apt, full package manager, mutable /usr
sudo apt update && sudo apt install -y build-essential git curl nodejs npm python3-pip

# Install yay in the Arch container for AUR access
distrobox enter dev-arch
# Inside:
sudo pacman -Syu --noconfirm base-devel git
git clone https://aur.archlinux.org/yay.git && cd yay && makepkg -si

# Export a GUI app installed in the container to the host desktop
distrobox-export --app code        # VS Code installed inside container, now in app launcher
distrobox-export --bin /usr/bin/node --export-path ~/.local/bin

The result is a fully mutable development environment where every package you install persists across SteamOS updates, because the container data lives in ~/.local/share/containers — inside /home, which is never touched by OS updates. You get complete access to apt, pacman, dnf, or whatever the container distribution provides, and the host OS remains pristine.

For a complete development workstation workflow, pairing a Distrobox container with VS Code (installed as a Flatpak on the host) and the Dev Containers extension gives you a familiar VS Code experience connected to a full development environment inside the container. See the Docker Compose homelab guide for patterns on how container-based development environments compose together in practice.

SSH Access and Using the Deck as a Remote Terminal

The Deck runs sshd via systemd but it is disabled by default. Enabling it takes three commands in Konsole.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# Step 1: Set a password for the deck user (has no password by default)
passwd

# Step 2: Enable and start the SSH daemon
sudo systemctl enable sshd --now

# Step 3 (optional): Find the Deck's IP address
ip addr show wlan0 | grep "inet "
# or
hostname -I

Once enabled, sshd persists across reboots in both Game Mode and Desktop Mode. You can now SSH into the Deck from any machine on your network:

1
2
3
4


# From another machine
ssh deck@steamdeck.local
# or by IP
ssh deck@192.168.1.x

If you use Tailscale, you can reach the Deck from anywhere on your tailnet without port forwarding. Installing Tailscale as a Flatpak does not work reliably because Tailscale needs kernel-level access; the better approach is to enter a Distrobox container and install the Tailscale binary there, or use the Tailscale Flatpak which has experimental support for the required capabilities. The Tailscale complete guide covers the networking side in detail.

For a homelab, an SSH-accessible Deck sitting on your desk becomes a convenient terminal for reaching the rest of your infrastructure. The 7-inch screen is usable for basic terminal work in a pinch, but the real value is remote access into the Deck itself — treating it as a node in your homelab network that you can reach from your workstation.

The Deck as a Portable Crash Cart

This is the use case that impresses people who work with physical server infrastructure. A crash cart — the wheeled console you roll up to a server when it will not boot and you need a keyboard and display attached — traditionally means a dedicated KVM console or a laptop and a crash cart adapter. The Deck does this job well because of its form factor, the USB-C port, and the fact that it runs a real Linux kernel.

The hardware you need: a USB-C to USB-A adapter (or a dock with USB-A ports), and a serial-to-USB adapter. Most server hardware exposes a serial console on an RJ-45 or DB-9 port at 115200 baud, 8N1. Plug the serial adapter into the Deck, and from inside a Distrobox container:

1
2
3
4
5
6


# Install minicom or picocom in your Distrobox container
sudo apt install -y picocom

# Connect to the serial port (adapter typically shows as /dev/ttyUSB0 on the host)
# You may need to pass the device to the container explicitly
distrobox enter dev-ubuntu -- picocom -b 115200 /dev/ttyUSB0

To pass host devices into a Distrobox container:

1
2
3
4


# Pass serial device on container creation
distrobox create --name crash-cart \
  --image ubuntu:24.04 \
  --additional-flags "--device /dev/ttyUSB0"

For servers with IPMI or iDRAC, you do not need a physical connection at all — SSH into the Deck from your Tailscale connection, and from there SSH into the management interface. The Deck becomes a jump box in your pocket. Combined with a small USB-C hub for power passthrough and a folding Bluetooth keyboard, it fits in a laptop bag alongside your laptop and weighs under 700 grams.

For direct KVM access to a server (not serial, but actual keyboard-video-mouse), a crash cart adapter like the ATEN CV211 accepts a standard USB-A connection and presents the host server’s video as a USB video device. Linux has decent support for USB video capture devices; you will want VLC or a similar application installed in a container to view the captured output, though latency is only suitable for console work, not interactive desktop sessions.

Running Containers and Dev Environments

Beyond Distrobox, the Deck can run conventional OCI containers via Podman directly. Podman is rootless by default on SteamOS, which aligns with how the Deck’s user model works. Running a containerized service for development purposes — a database, a local web server, a Redis instance — works without any special setup.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# Run a PostgreSQL container for local development
podman run -d \
  --name postgres-dev \
  -e POSTGRES_PASSWORD=devpass \
  -e POSTGRES_DB=myapp \
  -p 5432:5432 \
  postgres:16

# Run a local Redis instance
podman run -d --name redis-dev -p 6379:6379 redis:7-alpine

# Check running containers
podman ps

# Generate a systemd unit for persistence (lives in ~/.config/systemd/user/)
podman generate systemd --name postgres-dev --files --new
systemctl --user enable container-postgres-dev.service

Because these containers live entirely in your home directory (Podman’s storage is at ~/.local/share/containers), they survive SteamOS updates unchanged. The RAM constraint — 16 GB shared between CPU, GPU, and your containers — becomes real here. A Distrobox development container, a PostgreSQL container, a Redis container, Firefox with several tabs open, and a VS Code instance will collectively push the system’s limits. This is not a server. Do not run production workloads on it.

Emulation: The Deck’s Killer Non-Gaming Use Case

Retro game emulation is not non-gaming in the strict sense, but it illustrates the Deck’s versatility in a way that is worth covering. EmuDeck and RetroDeck are the two primary approaches to installing a full emulation stack on SteamOS.

RetroDeck is available as a single Flatpak from the Discover store. Install it, point it at your ROM directory on your microSD card, and you have a frontend that wraps RetroArch, Dolphin, PCSX2, RPCS3, Yuzu’s successor, and dozens of other emulators, all pre-configured for the Deck’s controllers and screen. RetroDeck 0.10 and later rewrote much of the internal tooling and added Azahar (a 3DS emulator) to the bundled set.

EmuDeck is a shell script installer rather than a Flatpak. It downloads emulators from their official sources, configures them, integrates with Steam ROM Manager to add individual games as Steam entries, and is generally more flexible for users who want to pick and choose individual emulators. The trade-off is that it requires running installer scripts and has more moving parts to maintain.

Both install almost entirely into your home directory and survive OS updates. The Deck’s x86-64 architecture means you get full-speed PCSX2, excellent Dolphin performance, and viable PS3 emulation via RPCS3 on less demanding titles — performance that is genuinely good given the hardware class.

Media Player, E-Reader, and Other Passive Uses

The OLED display on the 2023 revision is a high-quality 90Hz panel with HDR. As a media client for Jellyfin, Plex, or local video files, the Deck is quite good. Jellyfin Media Player, installed as a Flatpak, provides hardware-accelerated decode via the AMD VAAPI driver:

1
2
3
4
5


flatpak install flathub com.github.iwalton3.jellyfin-media-player

# If you need to verify VAAPI is working for hardware decode:
flatpak run --command=bash com.github.iwalton3.jellyfin-media-player
# Inside: vainfo

For e-reading, Okular (available as a Flatpak) handles PDFs, ePubs, and technical documentation well. The 7-inch screen at the Deck’s native resolution is a reasonable reading surface — smaller than a Kindle Scribe but functional for reading documentation, technical PDFs, or ebooks. The landscape orientation and 800p screen means long-form prose is serviceable but not optimal; portrait mode is blocked by the hardware layout.

Kodi is available on Flathub and works as a local media center application. For purely local playback of videos organized in a media library, it integrates cleanly with the Deck’s interface. VLC is similarly available and handles anything you throw at it without configuration.

Docking the Deck as a Desktop

A USB-C dock transforms the Deck into a small desktop workstation. Any USB-C dock supporting DisplayPort Alt Mode and USB Power Delivery works. Valve’s official dock is competent but unremarkable; third-party alternatives with 2.5G Ethernet ports are available and useful if you are doing heavy file transfers.

What you get at the dock: an external display at up to 4K 60Hz or 1080p higher refresh rates (exact limits depend on dock and cable), USB-A ports for keyboard, mouse, and peripherals, Ethernet, and power delivery to keep the Deck charged. The Deck’s display stays on as a second monitor by default, configurable in KDE display settings.

The thermal limits matter here. At the dock, running the Deck with a full KDE desktop, a browser, a Distrobox container doing compilation, and a container database, the APU will run warm and the fan will be audible. The TDP is adjustable — the built-in TDP controls that exist in Game Mode are not automatically carried over to Desktop Mode, but you can install tools inside a container or use the ryzenadj utility to manage TDP limits manually.

The RAM ceiling is the more limiting constraint for a docked workstation. 16 GB unified memory means the GPU is taking a portion of that pool for display output, leaving less for applications. Running three or four containers alongside a browser session will make the system uncomfortable. This is emphatically not a machine for running a full development stack with multiple services, a compilation job, and a browser — but for writing code, reading documentation, managing servers, and monitoring infrastructure, it is plenty.

Battery, Thermals, and Honest Limitations

The Deck’s battery capacity is 40 Wh on the LCD, 50 Wh on the OLED. At the TDP settings required for running a full KDE desktop with active processes, expect 2–3 hours of battery life in Desktop Mode under light to moderate load. Heavy container workloads will push TDP and drain battery faster.

The cooling system is designed around gaming workloads — intermittent bursts of GPU load followed by periods of lighter activity. Sustained CPU-heavy work (compilation inside a Distrobox container, for instance) stresses the thermal design in a different pattern and will cause the fan to run continuously at moderate-to-high speed. The fan is audible.

The ergonomics of holding the Deck for extended Desktop Mode sessions are poor. The device is not designed to be held like a laptop. For any serious work in Desktop Mode, you either dock it or set it on a surface and use it with an external keyboard and mouse while looking at the built-in display — which puts you in an awkward position relative to an 800p 7-inch screen. The screen is fine for remote SSH work and occasional terminal sessions. It is not a daily driver display.

For all these reasons, the Deck fits a specific niche: a secondary Linux machine, a travel workstation, a homelab tool, an emulation device, a crash cart. It supplements a primary machine rather than replacing one. Bazzite and other community-built SteamOS variants exist (running on the Deck or on devices like the ROG Ally) that replace the immutable base with a more mutable image, trading some update reliability for flexibility — but that is a separate conversation about choosing a different OS entirely, not about what vanilla SteamOS gives you.

Verdict

The Steam Deck is a real Linux computer. It runs x86-64 binaries, it has a full KDE Plasma desktop, it supports containers natively, and it fits in a bag. The immutable SteamOS base is not a limitation to work around — it is an architecture that works cleanly once you stop trying to install packages into /usr and start using Flatpak for GUI applications and Distrobox for development work. That pattern handles the majority of non-gaming use cases well.

Where it fails as a primary machine is clear: 16 GB of shared memory is a ceiling you will hit, sustained workloads fight the thermals, and the 7-inch 800p display is adequate rather than comfortable for full workdays. Where it succeeds is also clear: portable Linux terminal, crash cart, Jellyfin client, emulation machine, and SSH jump box into your homelab. At its price point, nothing else delivers this combination of portability, x86-64 performance, and a coherent Linux environment with upstream vendor support.

The correct mental model is not “gaming handheld that can run Linux.” It is “inexpensive portable x86-64 Linux PC that also runs Steam.” Most of the frustration people report comes from expecting it to perform like the former while ignoring what it actually is.