Machines
The Fyolo server
What runs on a machine so sessions outlive the app — how fyolod is installed, kept alive, updated in place, and inspected when something looks wrong.
Every session runs inside fyolod, the Fyolo server, on the machine that owns
it — including the ones on this Mac. The Mac app, the iOS app and the CLI
are all viewers: they attach to a session and detach from it. Nothing about a
session belongs to the window you were looking at.
That is the whole reason quitting Fyolo does not kill your agents.
What it is
fyolod is a session host, not a window manager. It owns the PTY, keeps the
scrollback, and hands a viewer a snapshot when one attaches. Locally a viewer
reaches it over a Unix socket; remotely the app opens an SSH pipe to the same
binary on the far box. One protocol, both ways — which is why a session on a VPS
behaves like a session here.
Panes, splits and layout are the app's business and never the server's.
Getting it onto a machine
Adding a box under Settings ▸ Remote Hosts and pressing Set Up copies one
binary into ~/.local/bin over SSH and starts it. There is no package to
install and no root involved.
fyolod deploy # install or update it here, then verify
fyolod deploy --host mybox # same, over your own SSH configdeploy is the only install path, and it is a reconcile: run it against a box
in any state and it ends in the same one. Fyolo reads ~/.ssh/config to find
the host, so a machine you can already ssh to needs nothing new. See
Devices.
Keeping it running
fyolod service install # launchd on macOS, systemd --user on LinuxWithout a service the server lives as long as your login session. With one it comes back after a crash and after a reboot, which is what you want on a box you only ever reach remotely.
Updating without dropping sessions
A new build replaces the running one in place: the process keeps its id and its PTYs, and the sessions never notice.
fyolod handoffThat is also what happens when the app updates itself — the reason a Fyolo update does not cost you your running agents. See What survives for every case, including the ones a handoff cannot cover.
Looking at it
Three commands answer nearly every "is it me or is it Fyolo" question:
| Command | What it tells you |
|---|---|
fyolod status | What this machine has: the binary, its version, and whether a daemon is answering on the socket. |
fyolod list | The sessions the host is holding — add --host <box> to ask another machine. |
fyolod logs | What the server recorded while nobody was attached. -f follows it; --path prints the file for a bug report. |
fyolod is the server's own command, and separate from the
fyolo command-line tool the app installs for you. You rarely
need fyolod by hand — the app runs these for you — but it is there when a
box is misbehaving and you want to look rather than guess.
Stopping it
fyolod stopIt declines while a command is still running or a viewer is attached, so a stray
stop cannot take an agent's work with it. Sessions end when their process ends,
or when you close them.
Remote hosts
The operational half of running agents on another box — adding a host, testing the route, why a password isn’t enough, what Set Up actually installs, and how to read the one line that says whether a machine is ready.
What survives
Sessions belong to the machine, not to the window — so closing, quitting, updating, and losing a connection all detach instead of killing. Here is exactly what survives each one, and what it costs when a process really does go away.