Vision
The long‑term vision of Mercurius is to make a remote workstation feel indistinguishable from a local one — not by compressing video, but by extending the workstation’s presence across the network with fidelity and intent.
In a mature Mercurius ecosystem, the device you use becomes irrelevant. A lightweight terminal, a tablet, or a browser becomes a portal into a powerful, long‑lived environment that follows you wherever you go.
Mercurius aims to restore capabilities that modern systems have quietly lost: structured windows, explicit focus, remote input semantics, and the ability to automate and introspect a workstation without resorting to pixel scraping or fragile hacks.
Mercurius is not an attempt to invent a new paradigm. It is an attempt to restore one that computing quietly abandoned. Once, many users shared a powerful machine through simple text terminals. When graphical interfaces arrived, X11 extended that model to windows and GUIs. Later, Wayland was designed for a world that assumed local, single‑user laptops were the norm, and that shared remote workstations were no longer part of everyday computing.
Over the same period, the rise of public clouds, private clouds, and on‑premises datacentres quietly shifted computing back toward centralised machines. Increasingly, development environments, data processing, and even graphics workloads run on hardware that is not the device in front of you. Laptops have become thin clients again in practice, but without a native, structured way to inhabit a remote graphical environment. SSH remains one of the most widely used network applications in the world because the terminal model never stopped being useful. What never emerged was its graphical successor.
Mercurius is an attempt to do for GUIs what SSH did for text: provide a secure, explicit, structured way to inhabit a remote machine as if it were local, without pretending that a video stream is a desktop. It is “X11 done right” for modern GPUs, modern networks, and modern expectations.
Mercurius aims to make it possible to:
- Run heavy applications on a central machine while interacting from anywhere.
- Use inexpensive, durable devices as thin clients that last a decade.
- Work with large datasets without syncing or copying them.
- Play high‑end games without local assets or GPU drivers.
- Move seamlessly between devices without losing windows, focus, or context.
- Automate and script the workstation using structured, explicit semantics.
This is not remote desktop, and it is not cloud computing. It is a new model of inhabiting a machine — one that treats your workstation as a stable, enduring presence, and the network as an extension of it.
Who Benefits
Mercurius is for anyone whose workstation is more than a disposable appliance. Engineers with large local datasets, developers with complex environments, musicians and artists with GPU‑heavy workflows, researchers with long‑running processes, and anyone who treats their machine as a place rather than a device all stand to benefit. These users already rely on fast networks, centralised storage, and long‑lived environments. What they lack is a graphical protocol that matches the rest of their infrastructure.
For small offices, one gaming-class machine could handle a roomful of quiet, fanless mini-PCs acting as pure terminals. For heavier creative studios, even a 1:2 or 1:4 ratio of users to hosts could reduce capital and maintenance costs while keeping performance predictable.
A recent experience was one of the drivers for this project, providing a concrete example. I was up early so logged into xavier on the console and started on some stuff. After a while it was time to head down to the studio, which meant logging out of xavier and logging in to flash, in another building. If only there was some way I could detach my KDE session on xavier before logging out (leaving the machine free for others to use) and pick it up again on flash. That is a use case mercurius is intended to address.
What Exists Today
Existing systems fall into two categories: legacy network transparency (X11 forwarding) and modern pixel streaming (VNC, RDP, SPICE, NoMachine, Sunshine). The former cannot support modern toolkits or GPUs; the latter moves images rather than windows, and cannot express structure, focus, or intent. None provide a way to inhabit a remote workstation with the fidelity of a local session. They solve different problems, and they solve them well, but they do not address this one.
Portals: A Powerful Capability Rebooted for the Modern World
Mercurius is first and foremost about letting you inhabit your remote workstation from the laptop or desktop you already use. But the same architecture also enables something broader: the ability to turn almost any small, inexpensive device into a secure, stateless access point known as a Portal.
A Mercurius Portal contains no user credentials, no reusable secrets, and no sensitive data. It authenticates the server using DNSSEC and DANE, presents the remote login environment, and holds no identity of its own. If a Portal is lost or tampered with, nothing is exposed. The device is interchangeable, disposable, and safe to deploy anywhere.
This opens the door to a wide range of possibilities: quiet fanless boxes in a teaching lab, shared desks in an office, lightweight devices in a studio, or dedicated access points in meeting rooms. Portals are not the primary use case for Mercurius, but they are a natural extension of its security model — a modern, practical way to put powerful workstations within reach of any seat in the building.
Use Cases
A number of use cases have driven the design of Mercurius. Some examples are given here.