A browser-based Linux desktop is exactly what it sounds like: a full graphical Linux environment — window manager, applications, file browser — running inside a Docker container on your server and streamed to a browser tab. You open a URL, and there is a desktop. No VNC client to install, no RDP gateway to configure, no X11 forwarding, no local software at all beyond the browser you already have open. This post explains how it works, what it is genuinely good for, and how to run one on your own server in a few minutes.
How does a desktop fit in a browser tab?
The technology behind this is a category called streaming workspaces. Inside the container, a real Linux desktop runs against a virtual display — there is no physical monitor, so the graphics are rendered to memory. A server component captures that virtual display and streams it to your browser over a web protocol, sending your mouse and keyboard back the other way. The browser is a thin client; all the actual computing happens on the server.
The images Panelica offers for this come from the Kasm Workspaces project, and they are ordinary Docker containers. That means everything you know about container management applies: resource limits, a private port, reverse-proxy access through a domain, and a persistent home-directory volume so your files survive a restart.
Why run a desktop on a server instead of on your laptop?
Several reasons, depending on who you are:
- The work should not run on your machine. Opening a suspicious file, testing malware, browsing a sketchy link — you want that happening in a container on a server you can throw away, not on the laptop with your bank tabs open.
- The work needs to be somewhere reachable. A desktop on a server is available from any device, anywhere, without carrying a laptop. Start a long task from your office desktop, check it from a tablet on the couch.
- The environment should be disposable and identical. A fresh desktop every time, pre-loaded with exactly the tools a task needs, with no configuration drift from months of use.
- The horsepower is on the server. A cheap client device drives a workspace backed by the server's CPU, RAM, and — for some images — GPU.
What can you actually run?
The catalog covers a wide range, all deployable as one-click containers:
| Category | Examples | Good for |
|---|---|---|
| Full desktops | Ubuntu, Debian, Fedora, and other Linux desktops | General-purpose remote workstation |
| Isolated browsers | Chrome, Firefox, Brave, Tor Browser | Opening risky links away from your real machine |
| Developer tools | VS Code, Cursor, and CLI environments for AI coding assistants | Coding from any device |
| Creative apps | Blender, GIMP, Inkscape, Audacity, LibreOffice | Occasional heavy tools without local installs |
| Security and OSINT | Kali, ParrotOS, and investigation toolkits | Disposable security labs |
Each of these deserves its own walkthrough, and we will cover the security and AI-coding ones in follow-up posts. This one is about the pattern itself.
Deploying one on Panelica
The flow is the same as any app template:
- Pick a workspace image from the Docker app catalog — start with a plain desktop if you are exploring.
- Set the access password. These images require a password (marked as a required secret in the template), so there is no unauthenticated desktop sitting open on the internet.
- Give it enough memory. This is the number people get wrong — a graphical desktop is not a lightweight web service. Most workspace images want around 2 GB of RAM minimum, and the template tells you so. Do not try to run one on a 1 GB VPS.
- Increase shared memory. Anything running a browser inside (which is most of these) needs a larger
--shm-size, or tabs crash. The template's advanced settings expose it. - Access it. Reach the workspace over its published port, or — the better way — link a subdomain like
desktop.example.comso you get HTTPS and a clean URL. The reverse proxy handles the WebSocket streaming automatically.
Persistence and disposability: pick one on purpose
These images mount a home-directory volume, so by default your files and settings persist across restarts. That is what you want for a workspace you return to. For the disposable use case — open one risky thing, then destroy all trace — deploy without caring about the volume and delete the container and its volume when done. The whole environment, and anything it touched, is gone. Deciding which mode you are in before you start is the single most useful habit with streaming desktops.
Frequently asked questions
Is the streaming smooth enough for real work?
For desktop applications, editors, browsers, and terminals — yes, comparable to remote desktop tools. It is not built for high-frame-rate gaming or video editing; those are latency-sensitive in ways screen streaming struggles with. Text and UI work stream very comfortably.
How many can one server run?
Budget by memory: at roughly 2 GB minimum each, a 16 GB server realistically hosts a handful of concurrent desktops, fewer if the tasks are heavy. CPU matters when they are all active at once. Set per-container limits so one workspace cannot starve the others — see our resource limits guide.
Is it safe to expose to the internet?
Only behind the password these images require, and ideally behind the panel's HTTPS reverse proxy rather than a raw published port. Treat the access password like SSH credentials, and consider restricting the domain to known IPs if the workspace is just for you.
Do I lose my work if the container restarts?
Not if the home volume is mounted — restarts preserve it. A container recreate (as opposed to restart) only preserves what lives in the volume, so keep working files in the home directory, not scattered across the container filesystem.
The takeaway
A browser-based Linux desktop turns any device into a thin client for a real workstation running on your server — disposable when you want to open something dangerous, persistent when you want a workspace to return to. On Panelica it is a one-click container like any other, with the two gotchas being memory (give it around 2 GB) and shared memory (raise it for anything with a browser). The rest of this series digs into the specific workspaces worth running.