How flue works
A daemon owns the shells. A tab renders them. What that buys you, and what it costs.
One daemon owns the shells
A small Go daemon holds the terminals and their scrollback. Everything that renders them is a client, including the tab you are looking at.
That single move is what the whole product rests on. A shell normally belongs to the window that opened it, so the window closing takes the work with it. Here the shell belongs to a process that outlives every window, and the window becomes a view rather than an owner.
Closing the tab detaches. The build keeps running, the agent keeps working, the SSH session stays up. Reattach and the daemon replays the scrollback you missed.
Every device is just another view
Because a client only renders, there can be more than one. Attach from two devices and they mirror live: typing on the phone shows up in the laptop's browser within a frame.
Size is negotiated rather than shared. The phone's 40 columns do not reflow the laptop, which is the failure that makes most screen sharing useless for real work.
One list, every machine
Pair more than one machine and the sessions screen shows all of them together, grouped by machine, with the same search, tags and pins across the whole fleet. Knowing what is running anywhere stops meaning logging into everywhere.
Installing it
One static binary, no runtime. flue enable installs a login service so the daemon comes back after a reboot, starts it, and opens the UI.
$ flue enable login service installed daemon running on 127.0.0.1:7717 opening http://127.0.0.1:7717
The daemon binds loopback and nothing else. Reaching it from another device is opt-in and is covered in remote access.
The CLI stays small
Everything after flue enable happens in the browser. The commands exist for the things a browser cannot do.
- flue enable
- Install the login service, start the daemon, open the UI.
- flue disable
- Remove it.
- flue status
- Daemon, login service and session diagnostics.
- flue open [path]
- Spawn a session here. Handy from a shell prompt.
- flue serve
- Run the daemon in the foreground, with no login service.
- flue relay setup
- Deploy a relay into your own Cloudflare account.
- flue relay join
- Point this machine at a relay another machine deployed.
Where the code is
The daemon, the web app and the relay Worker are all MIT licensed in one repository. The dev loop and the dev/prod split are in DEVELOPMENT.md, and the rough edges we already know about are in FOLLOW-UPS.md.