← All articlesConcepts

There is no port to open, and that is the point

· 4 min read

You want the agent running on the desktop under your desk, and you want to answer it from a laptop in a cafe. Historically that sentence ends in an afternoon of port forwarding, a router page you have not opened in three years, a dynamic address that moves, and a small permanent worry about what else can now reach that machine.

There is nothing to configure here, and the reason is worth understanding because it is also the security answer.

The direction is always outward

The Director on each of your machines dials out to your Gateway and keeps that connection open. Everything that reaches the machine afterwards - your phone answering a session, the Cockpit, a command from another agent - comes back down the connection the machine itself opened.

The Gateway never contacts your machines. It does not need to know how to, and it does not know how to. That is not a setting somebody chose to leave on; it is the only connection there is.

What that gets you

  • Nothing to set up. No port to open on any machine you connect, no forwarding rule on a router, no address that has to stay the same. A laptop that moves between four networks in a day is not a special case - it reaches out from wherever it is.
  • Nothing extra to find. A machine that never accepts an inbound connection has no extra surface exposed. The usual question about a remote-control tool - what can reach this box now - has the same answer it had before you installed anything.
  • It survives a network that moves. Because each machine owns its own connection, reconnecting is the machine's job, not yours.

The one listener, and the one exception

Stated plainly, because a claim like this is only worth anything with its edges on it. If you host the Gateway yourself, that Gateway listens on one port, on the single machine you chose to run it on. With the hosted Gateway, no machine of yours listens on anything at all.

The exception: during an interactive sign-in the Director opens a loopback listener to receive the callback from your browser. It lasts as long as the sign-in and carries nothing an agent can call. The claim is that the Director runs without a listening socket, not that it never opens one.

How it got here

Machines have connected across the network this way - outward, with no port to open - since that connection shipped in v1.1.0. What remained afterwards was local: the Director and the launcher each listened on a port of their own machine, and an agent could reach the fleet two ways. v1.9.9 deleted both. Everything an agent does now goes through the Gateway: one door, always. Leftovers from that era - port reservations, inbound mappings - are torn down automatically the next time a Director starts.

Worth separating one thing: this is about how machines connect, not where your work runs. Your coding agents still run in Directors on your own computers, on your own disk, with your own subscriptions.

The full picture: connecting machines without opening a port. For adding the second computer and starting sessions on it: running agents on more than one machine.

Run your agents from one control room

DevThrottle orchestrates command-line coding agents across your machines.

Create free account