# Keep a bench up without a window

The console stops every device when it closes. A bench that must keep its
instruments available — overnight, after a reboot, with nobody logged in —
runs `fleet run` instead:

```bash
plesty-server fleet run --agent
```

It starts the **working fleet** — the devices ticked in the console's *Fleet*
column — and then checks every few seconds. A device found `exited` is started
again, after a pause that doubles with each crash in a row (1, 2, 4 … up to
60 s) and resets once it runs again. A device you stopped yourself is left
alone. `--agent` also serves [the agent](remote.md), so the bench stays
reachable from other machines.

Ctrl-C, closing the terminal, or a service manager stopping it brings the
devices down with it, so stopping the service stops the bench cleanly.
`--leave-running` leaves them up instead — for restarting `fleet run` itself
without disturbing the instruments.

## Choosing the working fleet

Tick a device's **Fleet** check box in the console, or leave
*part of the working fleet* ticked when declaring it. A bench may declare a
dozen devices and keep three running.

## Start it with the machine

Register the command with the system's service manager, as the user whose
home holds the bench:

- **Windows** — a Task Scheduler task *At log on* or *At startup*, running
  `plesty-server fleet run --agent`.
- **Linux** — a systemd user service with
  `ExecStart=plesty-server fleet run --agent`.
- **macOS** — a LaunchAgent with the same command.

## One-off, without the loop

```bash
plesty-server fleet up        # install what is missing, start the working fleet
plesty-server fleet status
plesty-server fleet down      # stop everything started here
```

`fleet up` exits with an error when any device did not come up, so a startup
script can report it.

How the bench tracks processes it did not start itself, and stops them on
each platform: [Process management](../design/processes.md).