Lynx Desktop: many windows, one remote connection
Lynx Desktop puts the terminal, file explorer and remote desktop in one browser tab over a single connection to one device. What that changes about the work.
The last time I chased a failing service on a customer box, I counted what I had open. A terminal. A second terminal, because the first one was tailing a log and I wanted it to keep tailing. A file browser in a different client entirely. And a password manager sitting behind all of it, because the credential I needed was not in my head.
Four things, four connections, four sessions that could each drop without warning. Two of them did, while I was in the other window.
That is the ordinary way to work on a remote machine and it has always been a bit silly. Every one of those tools was pointed at the same computer. None of them knew the others existed.
Lynx Desktop is what we built instead. It runs in a browser tab and behaves like a desktop: floating windows you can move, resize and minimize, app icons on the wallpaper, a taskbar along the bottom listing what is running. Everything in it is talking to the same device over the same connection.
Tabs make you remember, windows let you look
The difference between a tabbed tool and a windowed one sounds cosmetic until you are doing something where two facts have to be true at the same time.
With tabs, you read the log, hold the error in your head, switch to the config, hold the config value in your head, switch back to confirm you read the log right. Every switch is a small act of memory, and memory at 2am is not what you would call reliable. With windows, you put the two side by side and stop remembering anything.
The icons on the wallpaper are the launcher. What appears there depends on the device and on your permissions, but the set includes Web Remote, Remote Access, Shell, Terminal, SSH, SFTP, File Explorer, Docker, Database, Credentials, Network Scanner, App Browser, Power Management, Activity Log and Task Manager. Apps you have no permission for are simply absent, so a junior technician and an admin open the same device and get different desktops.
A service that will not start
This is the case that made us build the thing.
A unit fails on boot. You open a Terminal window and run journalctl -u against it. You open a File Explorer window, walk to the config directory, and open the file. Text files open ready to edit rather than in a read-only preview, so you fix the line and save it without going anywhere.
Now the useful part. The terminal window is still there, still attached, still showing the log. You restart the service and read the result in a window you never had to leave and come back to. If you got it wrong, the config is one window over and still open at the same line.
Compare that to the tab version, where restarting the service means switching away from the editor, and reading the log means switching away from that. It is the same three actions either way. The difference is how much of the state you had to carry in your head between them.
The shape is identical on Windows, which is what the shot below happens to be.
The 2am disk page
Disk pages are mostly an exercise in searching. Something grew, and you do not yet know what.
The version of this I like: File Explorer open and sorted by size, walking down from the root a level at a time, while a Terminal window next to it runs whatever du incantation you actually remember. Two ways of asking the same question, running at once, and whichever one answers first wins. On a Docker host, a third window listing containers usually finds it faster than either.
Then you delete the thing, and the File Explorer window still knows where you were. That sounds small. It is not, at 2am.
Several of the apps open more than once, which is the part people find out by accident and then rely on. Two File Explorer windows at different paths, so you can compare them or drag between them. Two terminals, one running the long thing and one for everything else. Two SFTP windows when you are moving files between directories that are nowhere near each other in the tree. Each window keeps its own path, its own column widths and its own sort order.
Window positions are remembered per device, so the layout you built for a machine is the layout you get back the next time you connect to it. Only the geometry is kept, never the contents of what was in the windows.
Handing a box to someone who has never seen it
Onboarding is the quietest argument for this design.
The standard version is a wiki page listing four tools, three of which need installing and one of which needs a VPN profile, and a paragraph explaining which credentials go where. The new person spends their first afternoon on setup rather than on the machine.
The Lynx Desktop version is a URL and a login. What they can open is decided by their permissions rather than by what they managed to install, and every session lands in the audit trail the same way. Nothing about their laptop matters, which is a nice property when the laptop belongs to a contractor.
There is also a plain teaching benefit. Screen-sharing a windowed workspace where you can point at two things at once is considerably easier than narrating tab switches.
The strip along the bottom is doing real work
The taskbar lists the running windows and restores them when you click one, which is the part you expect. The part worth pointing at is the small cluster on the right: a connection quality indicator, a live latency readout in milliseconds, and a session timer counting how long you have been connected.
Those numbers are not there for a benchmark. They are there so that when something feels slow you can tell whether it is the link or the machine, without guessing. A latency figure that has crept up while you were working is a different problem from a box that is thrashing, and the two feel identical from the keyboard.
If you would rather not reach for the mouse, holding Alt and pressing the backtick key cycles through the open windows.
One connection, and why it matters here
Everything above rests on a single fact: the windows are not separate connections that happen to share a page. They ride one session to the agent on that device.
That is why the terminal does not drop when you switch to the file explorer, and why a reconnect brings the whole workspace back rather than four things individually. It is also why the latency number on the taskbar means something for every window rather than for whichever one happens to be in front.
The connection itself works the way the rest of our remote access works. The agent dials out, nothing on the target listens for inbound connections, and the browser meets it at the relay.
We wrote that model up properly in how VPN-free remote access works, so there is no point restating it here. The relevant bit for Lynx Desktop is that one connection covers the whole workspace.
It is not a desktop OS, and does not pretend to be
Worth saying plainly, because the screenshots invite the assumption. Lynx Desktop is a set of tools running against a device, presented in a window manager. The wallpaper is ours, not the target machine’s.
When you do want the actual desktop of that machine, that is the Web Remote app, and it opens as one of the windows. Which, honestly, is the neatest bit: the remote desktop becomes a window among the others rather than the thing you have to leave in order to check anything else. More on that whole surface on the remote desktop and SSH page.
Two servers, free forever. Sign up at app.lynxtrac.com if any of this resonates.
Related posts
Why remote access should never be a standalone tool
Remote access without context is just a shell in the dark. Access, monitoring, and audit belong on one surface rather than three separate purchases.
How VPN-free remote access works
What the outbound-agent model actually does, versus what a VPN does. Written because enough people have asked variations of 'so how is this different from Tailscale?'
Secure remote access for modern IT teams: what really matters today
Most remote access checklists are stuck in 2015. Here are the controls that actually matter for IT teams operating across cloud, hybrid, and remote-first realities.