Docs/Gateway/Keeping agents running
Gateway

Keeping agents running

4 min read

DevThrottle's promise is that you can look away without your agents stopping. This page is the honest map of how that works: which piece runs what, what keeps going when you close something, and what comes back after a reboot.

Three layers, three lifetimes

  • Viewers - the Cockpit in a browser, and your phone. Pure views. Open and close them as often as you like; nothing about your agents changes.
  • The Director - the desktop app that owns the agent sessions. The agent processes are its children: as long as the Director runs, your agents run, whether or not you are looking at any of it.
  • The Gateway - the always-on service that keeps everything reachable: by default DevThrottle's hosted Gateway, or one you run yourself. It does not run the agents itself; it serves the Cockpit and your phone, tracks the Directors on your machines, and sends the command that starts one when a scheduled run fires. On each machine a small Launcher - a tray app registered to start at login - holds the connection to the Gateway and starts and stops Directors when asked.
Note
The practical rule: walk away from the desk, close the browser, pocket the phone - agents keep working, and you can answer them from anywhere the Gateway is reachable. The Director window itself is the one thing to leave running.

Closing the Director

Because sessions live inside the Director, closing it ends them. Minimise the window rather than closing it.

Warning
Closing the Director ends the agent processes. Every change the agents made to your files stays - but in-flight work stops where it stands.

Starting and stopping the Gateway itself

If DevThrottle hosts your Gateway, none of this is yours to run - it is already on, and it stays on. What follows is for a Gateway you run yourself.

The Gateway is a headless background service. It has no window and it draws no screens: every screen it used to own lives in the Cockpit, which you reach by browsing to the Gateway's own address. So the only two controls it offers a person are Start and Stop - the two verbs a service has.

To have it come up on its own when you log in, use the command line:

Start the Gateway at login
cc-devthrottle autostart on       # start the Gateway when you log in
cc-devthrottle autostart off      # do not
cc-devthrottle autostart status   # whether it does, and the mechanism on this OS

It registers per user, using whatever the operating system already provides - the Run key on Windows, a launch agent on macOS, a systemd --user unit on Linux, which is what a headless server needs where no tray or window exists. status prints which one is in force on the machine you run it on.

The Gateway's own settings are not in a window either - they live in the Cockpit's Settings page. What the Gateway holds falls into two halves, and a restart treats them differently:

  • Kept in its database, so a stop and a start changes nothing. Schedules and their run history, session history, paired devices, skills and workflows, keys and settings. These are simply there again when it comes back.
  • Held in memory, and rebuilt after the restart. The live picture - which Directors are up right now, and the session state each of them is pushing - is a cache, not a record. A restarted Gateway starts with none of it and fills it from the machines themselves: each Director re-registers and pushes a fresh full snapshot of its sessions over its own outbound connection.

In practice that gap is short - a Director that is up re-registers and heartbeats on a fifteen-second cycle - and it needs nothing from you. But it is a real gap, and it is the one thing to plan around: for the moments right after a restart the Cockpit and your phone can show a thinner fleet than you have, and a machine that is off or offline stays absent until it comes back and reports in. Nothing is lost by this - the history of those sessions is in the first half above - but the live roster is reassembled rather than reloaded.

After a reboot

The Launcher registers itself to start at login (you can toggle that from its tray icon), so the machine comes back connected to the Gateway without any ritual. The recorded half above comes through a reboot untouched: scheduled jobs and their run history, paired devices, and machine settings. The live roster is reassembled as each machine comes back and reports in, the same way it is after a Gateway restart. Scheduled jobs recompute their next run time, and if a job fires when no Director is open, the Gateway has the Launcher start one - so unattended runs do not depend on you remembering to open anything.

Where to go next