Why the Fwoop agent never listens

When you install software that can deploy containers and run commands on your servers, the first question should be: how does it get its instructions?

There are two broad answers. Either the agent listens on a port and a central server connects to it, or the agent connects out to the central server and waits for instructions over that connection. The Fwoop agent does the second, and only the second. It never opens a listening socket.

Inbound means attack surface

A listening agent has to be reachable. That usually means opening a port in your firewall, running a VPN, or putting the agent behind a bastion host. Each of those is more infrastructure to secure, and the agent itself becomes a network service that anyone who can reach the port can probe.

An outbound-only agent flips that around. Your servers can keep a default-deny inbound firewall. Nothing about Fwoop shows up in a port scan, because there’s nothing to find:

$ sudo ss -tlnp | grep fwoop
$ fwoop agent status
connected · agent 2.3.1 · 0 inbound ports

It works where your servers are

Outbound connections also happen to work in the places inbound ones don’t: behind NAT, behind a corporate proxy, on a home connection with a changing IP. If the server can reach the internet over HTTPS, it can reach the control plane. That’s why a Raspberry Pi in a closet and a VPS in Frankfurt connect the same way.

What the connection carries

The agent opens a TLS connection to the control plane and keeps it open. Over it, the control plane sends instructions (deploy this release, run this job, take this backup) and the agent sends back results and metrics. Every instruction comes from an action in your workspace, and every action lands in the audit log with who triggered it.

Some things deliberately don’t travel over it:

• Your data. Containers, databases and logs stay on your servers. Logs stream to your browser when you ask for them; they aren’t stored by Fwoop.
• Backup contents. Snapshots are encrypted on the server and go straight to your bucket.
• Secrets at rest. The control plane stores secrets encrypted. Agents decrypt them only for the containers that reference them, in memory.

What if the control plane is down?

An outbound design raises a fair question: what happens when the agent can’t reach the other end? It keeps doing what it was doing. Services keep running, cron schedules keep firing from the agent’s local copy, and results queue up until the connection is back. You lose the ability to change things for a while, not the things themselves.

The short version

An agent that listens is an agent you have to defend. Ours dials out, keeps your inbound firewall closed and carries instructions, not data. That’s the default, and there’s no setting to change it.