Summary: Factory added a Remote Control mode to Droid that connects a Linux, macOS, or Windows machine you already manage — a VPS, cloud VM, workstation, or on-prem server — so the agent can work on it from the web or other devices. The connection runs outbound through Factory’s relay, so you don’t open inbound ports, and Droid reuses the git credentials and dev setup already on that machine. For builders, this means your agent runs where your code and config live, not in a disposable sandbox.
Why run the agent on your own machine?
Hosted agent environments are convenient until you need your real environment: the monorepo with internal remotes, the locally installed toolchain, the SSH keys and git config your team already trusts. Droid’s Remote Control docs make the tradeoff explicit — Factory does not provision or maintain your computer, and it does not manage git credentials on it. Your machine stays yours; the agent just gets a way in.
This is the same instinct I covered when putting an agent where your files already live: moving compute to the data beats copying the data to the compute. If your setup involves private package registries, signed commits, or a database only reachable from your network, a sandboxed cloud agent starts every task at a disadvantage.
How the connection actually works
The mechanics are simple. You need the Droid CLI installed and authenticated, plus network access to the relay for your region — relay.factory.ai for most organizations, relay.eu.factory.ai for EU ones. Then start the daemon:
droid daemon --remote-controlIf the machine isn’t registered yet, this prompts for a name and registers it. Only one registration is allowed per computer, so you’d run droid computer remove before re-registering. Alternatively, the Factory App can register the machine automatically by hostname — flip on Remote Control in Settings → Droid Computers and it stays reachable while the app runs.
The relay matters more than it first appears. Because your computer dials out to Factory rather than listening for connections, no public ports get exposed. That’s usually the deal-breaker for letting an external agent drive a machine behind a corporate or home network.
Daily driving it
Once registered, a few commands cover the workflow: droid computer list to see what’s connected, droid computer ssh <name> for a shell, and droid computer port-forward for TCP mappings over the relay — for example, forwarding local 8080 to remote 80. Updating means refreshing the CLI on the machine and restarting the daemon yourself.
Two ownership notes worth taking seriously. First, credentials: Remote Control uses whatever git configuration already exists on the machine, which is powerful and also means a compromised machine is a compromised identity. Second, hardening: Factory states plainly that you are responsible for maintaining the underlying computer. If you’d rather hand off that burden, Factory’s managed alternative is Droid Computers, their hosted persistent compute.
The tradeoff in one line
You’re choosing between control and convenience. Bring your own machine and you keep your environment, your credentials, and your security obligations. Use hosted compute and Factory keeps the box patched but you adapt your workflow to it. The practical next step: if your current blocker with web agents is “it can’t reach my repo/tooling,” try connecting one workstation via the relay and see whether the agent completes a real task end to end — that will tell you more than any feature list.
Sources
View the original post on X