Turning remote access on

The panel starts a small web server on your machine and a Cloudflare quick tunnel in front of it. What that starts, what it needs, and how to stop it.

What it starts #

Remote check-in lets you read a run from a phone, and answer it. AutoDev serves its own plane on 127.0.0.1, and a Cloudflare quick tunnel gives that plane a public address. AutoDev owns no server for this: cloudflared is Cloudflare's client, and AutoDev runs it and reads the address off its output. While remote access is on, what the phone reads and sends goes through that tunnel.

The tunnel is optional. Without it the plane still runs, but only this machine can reach it.

Turn it on #

In the panel, open the Config destination. It has a Remote access section, and while nothing is running it says Off — nobody outside this machine can reach this project. Press Turn on remote access.

That starts a detached, supervised server with a tunnel and the full telemetry tier. It uses port 8787, or the port and token of the last server when there was one. When that port is taken, the server uses a free one and writes a serve.port_taken warning to the event log. The button says Turning on… while it works, and the section leaves Off once cloudflared has announced an address, which can take up to a minute on a slow link. It then shows the address as text and as a QR code, a pairing code once you open one, and how many devices are paired. Pairing a phone covers the code.

cloudflared needs to be on your PATH, or named in AUTODEV_TUNNEL_BIN. It is needed for this and for nothing else. If it is missing, or does not announce an address, the server keeps running on this machine alone, and the address line reads Tunnel unavailable — loopback only. The reason is a warning event in the event log, serve.tunnel_failed. cloudflared missing covers it.

The tunnel belongs to the server's supervisor, not to the server process, so a restart of that process keeps the same address. If cloudflared exits later, AutoDev retracts the address: the line changes to Tunnel unavailable — loopback only, and a serve.tunnel_down warning names the reason. A dropped tunnel is not rebuilt on its own. Turn remote access off and on again to get a new address.

One machine, one server #

A machine runs one server, and it outlives the editor window that started it, so that a run you are checking from a phone does not end when you close the editor. It also means the server can be showing a different project from the panel you are reading. When it is, the section says Showing <project>, not this project. and offers Show this project instead. The phone's menu has the same switch. Neither offers to start a second server.

After a restart of the machine, autodev with no command, run in a project, starts the detached server again on the same port, token and tier. It starts it without the tunnel, so the address is gone until you turn remote access off and on. While a phone is paired, suspendOnCompletion does not suspend the machine.

Turn it off #

Press Turn off remote access. That stops the server and its tunnel together, so the public address does not outlive the plane it points at. Every paired device is forgotten with it. The limits of the tunnel says what that does and does not revoke.

From a terminal #

autodev serve runs the same server in the foreground, and --tunnel adds the tunnel. It prints the public address, and the token when it generated one, and it says that anyone with both can drive the run. A foreground server ends with its terminal and is not started again after a restart. autodev serve --daemon runs it detached and supervised like the panel's, and autodev serve stop stops it from any project. The panel sees a server started either way, and autodev serve pair opens a pairing code on it. Every CLI command lists the flags, and What you can do from the phone says what a paired phone gets.