---
title: "Deploy Ubuntu Desktop (Web GUI)"
description: "A real XFCE Ubuntu desktop in the browser, not just a web terminal."
category: "Other"
url: https://railway.com/deploy/ubuntu-desktop-web-gui
---

# Deploy Ubuntu Desktop (Web GUI)

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

**[Deploy Ubuntu Desktop (Web GUI) on Railway](https://railway.com/template/ubuntu-desktop-web-gui)**

- **Creator:** darseen
- **Category:** Other

## Template content

### desktop https://devicons.railway.com/i/ubuntu.svg

- **Image:** linuxserver/webtop:ubuntu-xfce
- **Start command:** `/bin/sh -c 'rm -f /etc/apt/apt.conf.d/20packagekit; exec /init'`
- **Public domain:** Yes

## Documentation

# Deploy and Host Ubuntu Desktop on Railway

Ubuntu Desktop is a full XFCE graphical desktop that runs in your browser, not a
terminal. It gives you a real Linux 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 Ubuntu Desktop

Deploying runs a single container built from `linuxserver/webtop:ubuntu-xfce`,
which serves the entire desktop over one HTTP port through its bundled nginx.
One thing is worth knowing before your first deploy. **The desktop
costs meaningfully more than a terminal template: 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**.

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: Burp Suite, Wireshark on a capture file, Ghidra, GIMP, 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 Ubuntu 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

- [linuxserver/webtop](https://github.com/linuxserver/docker-webtop) - the upstream image
- [Docker Hub image](https://hub.docker.com/r/linuxserver/webtop)
- [Selkies](https://github.com/selkies-project/selkies) - the streaming layer
- [LinuxServer Webtop documentation](https://docs.linuxserver.io/images/docker-webtop/)

### 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.

**Image tag.** The floating `ubuntu-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 Ubuntu 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 Ubuntu 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.


## Similar templates

- [Rocky Linux](https://railway.com/deploy/rocky-linux) — Hosted Rocky Linux 9 workspace with SSH and persistent storage. 🚀
- [Foundry Virtual Tabletop](https://railway.com/deploy/X5tR6G) — A Self-Hosted & Modern Roleplaying Platform
- [Letta Code Remote](https://railway.com/deploy/letta-code-remote) — Run a Letta Code agent 24/7. No inbound ports, just deploy.

Open this page in a browser: https://railway.com/deploy/ubuntu-desktop-web-gui