Tomorrow’s frontiers, inhabited from wherever you are.
Mercurius imagines a world where any machine can be inhabited from any other.
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 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. This model is symmetric: any machine can inhabit any other, and your account is the centre of gravity rather than the device.
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.
A Mercurius session is intended to persist independently of the portal currently attached to it. You should be able to leave a live graphical session running on your workstation, detach from it, and later resume the same environment from the same or another device without logging out, restarting applications, or reconstructing context.
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
Portals make it practical to use dedicated, stateless devices as graphical seats on a powerful workstation. Thin clients never disappeared; they continued in places where the model still made sense—branch offices with dedicated links, secure environments with no tolerance for local data, and sites without on‑site IT. What was missing was a way to support this model cleanly for modern graphical workloads. Mercurius restores that capability. A Portal is simply the place you sit: it may be the workstation’s own console, a laptop, or a small appliance built for this purpose.
Because a Portal holds no applications, configuration, or user data, it can be silent, durable, and easy to deploy. The Session lives entirely on the workstation, which provides the performance, storage, and graphics. The Portal provides the desk. This separation makes dedicated thin‑client hardware viable again—not as a nostalgic return to older systems, but as a practical response to modern workloads that benefit from centralised compute and lightweight endpoints.
In classrooms, labs, and offices, several Portals can attach to their own Sessions on a single machine, each with a full environment without requiring local maintenance. A Portal contains no reusable secrets and no sensitive data; it authenticates the workstation using DNSSEC and DANE and leaves nothing behind. If a device is lost or tampered with, nothing is exposed. This makes dedicated appliances safe to deploy widely, while remaining only one of many ways to access a Mercurius Session.
This opens the door to quiet fanless boxes in teaching labs, shared desks in offices, lightweight devices in studios, 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.