Questions worth a straight answer
Including the one where the honest answer is not the flattering one.
Can flue read my terminal?
No. There is nothing of ours in the path to read it with.
There is no flue server. Local sessions never leave your machine. Remote ones cross a relay that runs in your Cloudflare account, not ours.
Can Cloudflare read it?
Not in transit. But encryption is not the whole story, and the rest matters.
Your browser and your daemon run a Noise IK handshake directly with each other. Your browser pinned the daemon’s key when you paired the device. Everything after that is ciphertext, and the relay holds no key for it.
Here is the part encryption does not fix. The web app’s JavaScript is served by the relay origin, so you are trusting that origin to serve the published code. The code that holds your keys is code you fetched. This is true of every end-to-end encrypted web app, and it is true of this one. Self-hosting is the answer flue has, which is why it is the only way flue is deployed.
The full version, including the exact move a hostile origin would make and what we do about it, is in the repository’s FAQ.
Does flue run any servers?
No, and none are planned.
flue relay setup deploys the Worker and the web app into your own Cloudflare account. No flue account, no billing, nothing of anyone else’s between your browser and your machines. flue.sh is a landing page and stores nothing.
What does it cost?
Nothing. It is MIT licensed, and Cloudflare's free plan covers personal use.
The relay is a Worker with one Durable Object per machine, plus one more for the fleet directory. What it deploys and what the caps are is in the relay runbook.
Do I have to set up remote access?
No. The daemon listens on loopback and nothing else until you ask for more.
Remote access is one opt-in command. Skip it and flue is a local tool that happens to keep your sessions alive. The steps, if you want it, are in the setup guide.
How many relays do I need?
One, for all your machines.
Run flue relay setup on one machine, then run the join line it prints on every other machine. Running setup a second time does not add a relay. It replaces the one you have, with a fresh secret and a fresh fleet key, so every machine then has to re-join with the newly printed line and every device has to pair again.
Do I have to pair my phone with every machine?
No. Pair it once and it reaches the whole fleet.
The machine that runs the pairing signs a device certificate that every machine in the fleet accepts. You do pair per browser, though: Safari and Chrome on the same iPad each hold their own keys, so each one pairs on its own.
What happens when I close the tab?
Nothing. Closing detaches the session. It does not kill it.
The session owns its shell and its scrollback, so the build keeps running. Reattach from any device and it replays what you missed.
What happens to my sessions when flue updates or restarts?
Nothing. Sessions outlive the daemon.
Every session runs in its own small holder process, separate from the daemon. Update flue, restart it, even have it crash: the shells and agents keep running, and the next daemon picks them back up with their scrollback intact. A machine reboot is the one thing that ends a session, and even then flue brings it back with its history, a fresh shell, and the command that resumes the agent conversation it was in.
Can two devices use one session at once?
Yes, and they mirror live.
What you type on the phone appears in the laptop’s browser. The terminal takes the size of whichever view you are using, so picking up the phone fits the session to the phone, and your next keystroke on the laptop fits it back.
What happens to sessions on a laptop that goes to sleep?
They stop running, and they come back when it wakes.
Nothing is lost. The switcher still shows the ones this browser has opened before, greyed and marked unreachable, and it still opens them. It remembers per browser, so your phone lists where your phone has been. If a job needs to keep going while you are away, start it on a machine that stays on: a desktop, a Pi, a VPS.
Which platforms?
macOS, Linux and WSL, as one static Go binary.
No Node, no Python, no toolchain. Windows works through WSL.
What can a relay operator see, even encrypted?
Who connected, when, how much traffic moved, and the whole pairing exchange.
Enough to analyse a session, never to read one. The pairing exchange is worth naming rather than filing under metadata: it crosses a cleartext control channel carrying a single-use token that lives two minutes. The full list is in the protocol spec.
Other pages
- Setting up your fleet One relay, every machine joined to it, every device paired once.
- How flue works A daemon owns the shells. A tab draws them. What that gives you, and what it costs.
- Remote access How a machine becomes reachable from anywhere, on infrastructure you own, in one command.