Deploy Debian Desktop (Web GUI)

A real XFCE Debian desktop in the browser, not just a web terminal.

Deploy Debian Desktop (Web GUI)

Just deployed

/config

Deploy and Host Debian Desktop on Railway

Debian Desktop is a full XFCE graphical desktop that runs in your browser, not a terminal. It gives you a real Debian 13 (trixie) GUI with a file manager, a browser, audio and a shared clipboard, reachable from any device at a URL, with no VNC client, SSH key or local VM.

About Hosting Debian Desktop

Deploying runs a single container built from linuxserver/webtop:debian-xfce, which serves the entire desktop over one HTTP port through its bundled nginx. Deploys complete in under a minute. The one thing worth planning for is cost: a desktop is not a terminal, and it idles near 800 MB of RAM with a session attached, against roughly 64 MB for a ttyd shell. Enabling serverless is strongly recommended so it suspends when you close the tab and you pay for the hours you actually use it.

The service intentionally has no healthcheck. HTTP basic auth covers every path including /, so Railway's unauthenticated probe is answered with 401 and the deploy would never go healthy; an always-on restart policy covers crashes instead.

Common Use Cases

  • Running GUI tools that have no terminal equivalent: Wireshark on a capture file, Ghidra, GIMP, a database client, or a full desktop browser
  • A persistent cloud workstation reachable from a locked-down machine, a tablet, or a Chromebook
  • A disposable, isolated browser and desktop for testing sites, extensions or downloads away from your own machine

Dependencies for Debian Desktop Hosting

  • A Railway volume, mounted at /config, which holds the desktop's home directory. Without it every file, setting and installed app is lost on redeploy.
  • Nothing else. There is no database, no external API key, and no GitHub repo behind the template.

Deployment Dependencies

Implementation Details

Why a single port is enough. Selkies uses a separate websocket server on 8082, which looks like it needs a second public port. It does not: the image's nginx reverse-proxies it internally.

location /websocket {
    proxy_pass http://127.0.0.1:8082;
}

Why no TURN server is needed. Selkies is often assumed to require STUN/TURN to traverse a reverse proxy, which Railway's HTTP-only edge could not provide. In this configuration it never negotiates WebRTC at all. The browser console on a live deploy reports:

Streaming mode set to: websockets
Pre-flight checks passed: Secure context and VideoDecoder API are available.
[websockets] Connection opened!

Video is H.264 encoded server-side and decoded in the browser through WebCodecs over that websocket. WebCodecs requires a secure context, which Railway's edge TLS supplies to the browser even though Railway speaks plain HTTP to port 3000.

The wallpaper fix. Out of the box this image renders a solid black desktop. Debian's xfdesktop ships no default backdrop, and the backdrop setting is keyed by monitor name; Selkies names its monitor selkies-primary, which matches nothing in a fresh profile. The template's start command seeds the backdrop once, then hands off to the image's own init:

XD=/config/.config/xfce4/xfconf/xfce-perchannel-xml
if [ ! -f $XD/xfce4-desktop.xml ]; then
  mkdir -p $XD
  # ...writes /backdrop/screen0/monitorselkies-primary/workspace0/last-image
  chown -R 1000:1000 /config/.config
fi
exec /init

The if guard means it runs only on an empty volume, so changing the wallpaper from the desktop's own settings sticks across redeploys.

Image tag. The floating debian-xfce tag is used rather than a pinned version hash. Railway templates have no update mutation, so a pinned tag would strand every deployer on a frozen image; for a desktop with passwordless sudo, missing weekly OS security rebuilds is the worse trade.

Security model. You choose CUSTOM_USER and PASSWORD at deploy time, and they are the only thing between the public Railway URL and a desktop with passwordless sudo and a terminal. Anyone who reaches the URL with those credentials can install and run anything and probe Railway's private network.

Both are required at deploy time, so Railway will not let you deploy without setting them. Do not clear PASSWORD afterwards: a blank value does not lock the desktop down, it disables authentication completely. The image only enables its nginx basic auth when the variable is non-empty, so an empty value serves the desktop to anyone who loads the URL.

HARDEN_DESKTOP=true disables sudo, terminals and the open-with tools if you want a locked-down desktop.

Why RAILWAY_RUN_UID=0. The image's s6 init has to start as root so it can chown the mounted volume and then drop the desktop session to PUID/PGID. Pinning the run uid to 0 keeps that sequence intact on a root-owned Railway volume.

Why Deploy Debian Desktop on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Debian Desktop on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.


Template Content

More templates in this category

View Template
Rocky Linux
Hosted Rocky Linux 9 workspace with SSH and persistent storage. 🚀

codestorm
45
View Template
Foundry Virtual Tabletop
A Self-Hosted & Modern Roleplaying Platform

Lucas
71
View Template
Letta Code Remote
Run a Letta Code agent 24/7. No inbound ports, just deploy.

Letta
51