How Finestra compares to other web desktop projects
daedalOS, Puter, Webtop, xpra, Greenfield and Cockpit are all excellent, and none of them is doing the same job. A tour of the browser-desktop landscape, and the one question Finestra answers.
Every time I show Finestra to someone, the second question is the same: isn’t this just daedalOS? Or Puter, or Webtop, or “that thing my friend runs in a container”.
It is a fair question, and the answer needs more than a feature table. “Desktop in a browser” sounds like a generic product, but it could be many things, and the projects in each are answering different questions. Once the questions are on the table, the landscape sorts itself out. The cool thing is that most of these projects are not competing with each other at all.
Some of this questions that help to classify the projects could be:
- Where does the computing happen? In the tab (client-side), in a container (isolated from the host), or directly on a machine you already own?
- What is the filesystem? A synthetic one, or a real one with your files in it?
- Is the unit a screen or a window? One framebuffer streamed, or individual application windows composited into a web page?
- Who is it for? Many tenants, or one person and their own machines?
Here is the quick review we did. All of these options are actually awesome, and several are better than Finestra at things Finestra does not attempt.
The browser is the computer
daedalOS is one of the most impressive on GitHub. A complete Windows-shaped desktop — window manager, taskbar, file associations, wallpapers — running with no server at all. The filesystem is BrowserFS over IndexedDB. It reads ZIP, ISO, 7z, RAR and TAR. It bundles thirty-odd applications: Monaco, Webamp, a PDF viewer, an IRC client, Stable Diffusion, and emulators — js-dos, BoxedWine, v86, Ruffle — so DOS games, Windows binaries and Flash all run in the tab.
“No backend” is the whole point. Every feature has to live entirely in browser APIs: Web Workers, OffscreenCanvas, IndexedDB. It is just an URL and closing the tab has no consequences.
WebVM deserves the same breath from the opposite direction — an actual Debian userland running through an x86-to-WASM JIT, in the tab, no server. Real Linux, no host.
By design, neither touches a machine, it will never break anything.
The internet computer
Puter is the most ambitious project on this list. It is a cloud OS: accounts, a real backend, its own filesystem, an app store, and — for developers — AI, storage, database and serverless workers behind one SDK. It is AGPL, self-hostable with a script or Docker, and also runs as a service at puter.com. The scope is enormous and the execution is good.
Puter’s apps are web apps written against Puter’s SDK, and its filesystem is Puter’s filesystem. Self-hosting moves that cloud onto your hardware; it does not turn Puter into a tool for administering the machine underneath. That is not a gap, it is what being multi-tenant means. You cannot hand every user a root shell on the host and still be a platform.
OS.js has been quietly doing a well-architected version of this idea since long before it was fashionable, with a proper VFS abstraction and a clean application model. Worth reading if you are building a shell of your own.
The whole desktop, in a container, streamed
Webtop from LinuxServer.io is
probably the most-deployed thing here, and deservedly: docker run, and you have
a full XFCE, KDE, MATE or i3 desktop in a browser tab, on Ubuntu, Alpine, Arch
or Fedora. Recent versions moved to Selkies with Smithay and labwc, and they
do GPU zero-copy encoding across Intel, AMD and Nvidia. That is well ahead of
what most projects in this space manage — a serious streaming pipeline, not a
noVNC wrapper.
Kasm Workspaces industrialised the same idea for enterprises — ephemeral, disposable, containerised desktops and browsers — and Flowcase is a fully open-source take on it.
The thing to understand about this family is that the container is the feature. The desktop you get is the container’s desktop; it is isolated from the host on purpose, and it evaporates when you are done. If the question is “how do I give fifty people a disposable Linux desktop”, or “how do I run something risky well away from my real system”, this family is the right answer and I would point you at Webtop first.
The gateway
Apache Guacamole is clientless remote desktop as infrastructure: RDP, VNC and SSH brokered through a browser, with no agent on the target. x2go does the NX thing for bandwidth-constrained links, and MeshCentral covers fleet remote management.
Guacamole in particular is the sort of software that keeps working for a decade. If you have a heterogeneous estate of Windows and Linux boxes and need one browser front door to all of them, use Guacamole. It is solving a connectivity problem, not a desktop-design problem.
Individual windows, forwarded
This is where it gets technically fun, and it is the family Finestra belongs to.
xpra — “screen for X” — has been doing seamless application forwarding for over a decade. Not a framebuffer: individual windows, detachable and reattachable without losing state, with a built-in HTML5 client so the far end needs nothing installed. It forwards audio, clipboard, printers, notifications and webcams. It is mature, it is GPLv2+, and if all you want is this one Linux application, in my browser, now, xpra is a battle-tested answer that has forgotten more edge cases than most projects have hit.
Greenfield is the most conceptually audacious project I have read in this space: a Wayland compositor written in TypeScript that runs inside the browser, with WebAssembly and WebGL for the hot paths. Native applications connect through Westfield, which generates JavaScript RPC stubs from the Wayland protocol XML so that a real Wayland client can talk to a compositor living in a tab; frames arrive GStreamer-encoded and land in a WebGL texture. It can also run WebAssembly-compiled Wayland applications entirely client-side. The architecture is a genuine inversion of the usual one, and it is worth an afternoon of reading whatever you are building.
web-desktop-environment by Shmuel Hizmi is the closest thing to a peer for what I am doing: a React shell over a Node backend, with its own Terminal, Explorer, Notepad and VS Code applications, and third-party X11 applications brought in through xpra. The same instinct — that a desktop metaphor is a good interface to a server — arrived at independently, and the react-fullstack approach to the client/server seam is clever.
And the other half: managing the machine
No list like this is honest without Cockpit. It is the best web interface to a Linux server that exists: storage, networking, virtual machines, SELinux troubleshooting, logs, updates, a terminal — polished, backed by Red Hat, and shipping in the distribution. Webmin predates nearly everything here and still works. CasaOS brings a friendly, desktop-flavoured UI to home servers.
Cockpit is better than Finestra’s system manager at several things and will probably stay that way. It is pages rather than windows, and it does not try to run GIMP — which is exactly the right scope for what it is.
So where does Finestra sit?
| Project | The unit | Real Linux applications | Relationship to the host |
|---|---|---|---|
| daedalOS, WebVM | The tab | Emulated / WASM | None, by design |
| Puter, OS.js | A cloud account | No | Its own VFS |
| Webtop, Kasm, Flowcase | A container desktop | Yes | Deliberately isolated |
| Guacamole, x2go | A remote session | Yes | Whatever the protocol exposes |
| xpra, Greenfield | A window | Yes | No shell around it |
| Cockpit, Webmin | A management page | No | Deep |
| Finestra | A window, in a shell | Yes | It is the host |
Finestra takes the seamless-window idea from xpra and Greenfield, puts it inside a shell like daedalOS’s, and points the whole thing at the machine it is installed on.
Concretely: it installs onto a headless Linux box with one command, runs as
you rather than as a service account, and gives you a taskbar with a real
PTY, a file manager walking your actual disk, a system manager reading /proc,
/sys, systemctl and journalctl live — and native Linux GUI applications,
each drawn by a small headless Wayland compositor written in C for this, and
composited into the page as an ordinary window.
There is no container, no agent, no synthetic filesystem and no account system. The authentication boundary is the SSH tunnel you already use to reach the box, which is why the server binds loopback by default: if you can reach the port, you already had that user’s shell.
That combination — per-window native applications, and real host administration, and a desktop shell, on the machine itself — is the one row in that table nobody else is standing on. Not because it is a better idea than the others, but because it answers a different question: “I have SSH’d into a server with no display, and I want windows instead of tmux panes.”
What that costs
Choosing that row means giving things up, and it is only fair to say which.
- Webtop and Kasm win on video. GPU zero-copy encoding is real engineering; Finestra ships damage frames over a pipe. For anything high-framerate, use theirs.
- xpra wins on peripherals. No audio, clipboard, printer or webcam forwarding here yet.
- Puter wins on everything multi-tenant, which Finestra will never do: one person, their own machines.
- Cockpit wins on management depth for storage, virtual machines and SELinux.
- daedalOS wins on delight per byte, and needs no server whatsoever.
- And touching real hardware has a price. Native modules pin the Node ABI, glibc
and the architecture, so releases ship a bundled runtime and are
acceptance-tested on five distributions before they go out.
docker runis a much easier promise to keep.
Pick by the question you are asking
- Show me something delightful, right now, with nothing installed. → daedalOS
- I want a cloud platform with users, storage and an app ecosystem. → Puter
- Give fifty people a disposable Linux desktop. → Webtop or Kasm
- One browser front door to a mixed estate of machines. → Guacamole
- Just this one GUI application, forwarded, reliably. → xpra
- I want to understand what a browser-native compositor could be. → Greenfield
- Administer my server properly from a browser. → Cockpit
- My headless box, with with a desktop environment via web — a terminal, files, the journal, and the occasional real GUI application, in my browser. → that is the one I am building.
The best of it? It is lightweight and simple to install. Try it today at finestra.dev