Remote access

On your home or office network, codeout works out of the box. To reach it from outside, you give your devices a path to the daemon. codeout makes that path easy without ever weakening the encryption, and without ever exposing your home address.

The model

There is no relay in the middle. The daemon listens locally; your paired devices connect to it. When the daemon and the device are on the same network, that connection is direct. When they are not, you put a transport between them, and the channel stays encrypted end to end across it. There are three ways to provide that transport, from least to most setup:

Direct (default)

Same LAN or same tailnet. Nothing to set up. The device reaches the daemon as if it were next to it.

codeout --public

One command. codeout.dev stands up a tunnel for you and gives you a public address to pair against.

Self-hosted tunnel

Your own Cloudflare Tunnel, SSH reverse tunnel, or reverse proxy. You own every hop.

Direct, on the same network

This is the default and needs no configuration. Run the daemon, pair a device on the same Wi-Fi, and you are done. The daemon binds to loopback and your LAN, your device dials it directly, and nothing leaves the network. If you never use codeout away from home, you never have to read the rest of this page.

Direct, over Tailscale

A private mesh VPN is the cleanest way to extend that direct connection beyond the LAN. Install Tailscale on the daemon host and on your devices, sign in to the same tailnet, and your phone reaches the daemon over its tailnet address as if it were on the LAN. No ports opened to the public internet, no tunnel, no third party in the path.

daemon host
# install and join your tailnet
$ tailscale up
# find this host's tailnet address
$ tailscale ip -4
100.x.y.z
# reach the daemon from any device on the tailnet
http://100.x.y.z:8400

One-command tunnel

When you want a public address without standing up your own infrastructure, run codeout with the public flag. codeout.dev runs the tunnel endpoint for you, hands you a public URL, and your daemon connects out to it.

~/projects/app
$ codeout --public
codeout -> http://localhost:8400
public  -> https://calm-otter-2f91.codeout.dev
pair a device against the public address above

Pair against the public address and you are reachable from anywhere with a browser. This is the easiest remote option, and it is still private, for the two reasons below.

Your home IP is not exposed

The daemon dials out to the tunnel. It does not accept an inbound connection from the public internet, so there is no port to open on your router and nothing for the public to scan. The world only ever sees Cloudflare's address, never yours. Compared with opening a port and pointing a DNS record at your house, this is genuinely more private: your home address never appears on the wire that strangers can see.

Self-host your own tunnel

Prefer to own every hop? Any tunnel that forwards to the daemon's local port works. Run your own Cloudflare Tunnel, an SSH reverse tunnel, or a self-hosted reverse proxy, point it at localhost:8400, and pair against its address.

daemon host
# example: an SSH reverse tunnel to a box you control
$ ssh -R 8400:localhost:8400 you@your-vps
# then pair against your-vps:8400

The encryption holds regardless

Important

A tunnel only moves bytes. It never gets the keys. The device-to-daemon channel is encrypted end to end, so there is no relay required, and any tunnel only ever sees encrypted blobs. A public tunnel, a curious proxy, or codeout.dev itself sees nothing but sealed ciphertext. Pick the option you trust to keep your daemon reachable, not to keep it private. Privacy is already handled by the encryption.

That is the load-bearing point of this whole page. The transport is interchangeable precisely because it is untrusted by design. You are choosing how the traffic travels, not who gets to read it, because the answer to who gets to read it is always: only your daemon and your device.

Binding and ports

default port
8400
default bind
loopback, so nothing is exposed until you put a VPN or tunnel in front of it
going remote
prefer a VPN or an outbound tunnel over binding to a public interface. The encryption holds either way, but a closed inbound port is one less thing to think about and one less thing to scan.