Remote Access

Remote access gives your daemon a public web address so the Snippbot mobile app can reach it when you are not on the same network.

You probably don't need this at home

On your own wifi the app already finds the daemon by itself — it scans the local network and the daemon advertises itself over mDNS. Pairing works, chat works, nothing needs configuring. Remote access is only for leaving the network.

It is off by default, and turning it on is a decision worth making deliberately. This page covers what it does, what it exposes, and how to switch it off again.

---

What it actually does

Your daemon listens on 127.0.0.1:18781 — the loopback interface, reachable only from the machine it runs on. Remote access starts a tunnel: a small program that holds an outbound connection to a tunnel provider, which in turn accepts public requests and forwards them down that connection to your daemon.

Nothing is opened on your router. No port forwarding, no firewall changes, no static IP. The tunnel dials out, so it works from behind NAT.

  phone (cellular)  ──►  tunnel provider edge  ──►  cloudflared  ──►  127.0.0.1:18781
                          (public hostname)         (your machine)      (your daemon)

---

Setup

1. Install a tunnel program

Snippbot does not bundle one — that would mean shipping and updating a binary per platform. It uses one you install:

# macOS
brew install cloudflared

# Windows
winget install --id Cloudflare.cloudflared

On Linux, grab a package from Cloudflare’s downloads page.

cloudflared is the default because its quick tunnels need no account at all — no signup, no dashboard, no credit card. ngrok is also supported for anyone who prefers it.

ngrok can't usually do both jobs at once

If you use messaging channels, the channel adapter already holds an ngrok agent session, and the free ngrok plan allows exactly one at a time — a second dies with ERR_NGROK_108. Snippbot detects this and marks ngrok unavailable for remote access with an explanation. Use cloudflared, or a paid ngrok plan.

2. Turn it on

Go to Settings → Remote Access and flip the toggle. You will be asked to confirm — read that dialog rather than clicking past it; the What this exposes section below is the same information.

The address can take up to a minute to become reachable. The tunnel itself registers in a few seconds, but public DNS has to propagate before anything can resolve the new hostname. This is normal and not a failure.

3. Pair your phone

Still in Settings → Remote Access, choose Show pairing QR, then scan it — either with the scanner inside the Snippbot app, or with your phone’s ordinary camera app. Both work; scanning from the camera opens Snippbot on the pairing screen.

The QR carries the address and a one-time pairing token, so there is nothing to type. It expires after about a minute and works only once — if it lapses, generate a fresh one.

Re-scanning a fresh QR on a phone that is already paired is fine, and is how an existing device picks up your public address after you turn remote access on.

Your phone stores both addresses: your daemon’s local one and the public one. It prefers the local network when it can reach it, and falls back to the tunnel when it cannot. Walking out of the house needs no action.

---

What this exposes

Worth being plain about, because the point of the feature is to make your daemon reachable:

• Everything the daemon can do becomes reachable at a public address. That includes your agents and the tools they can run.
• Requests still need credentials. Your API key is required, and each paired device gets its own token that you can revoke individually from Settings → Devices.
• The tunnel provider terminates TLS. Traffic is encrypted between your phone and their edge, and between their edge and your machine — but they can see it in the clear in between. You are trusting them with it.
• A quick tunnel’s hostname is obscure but not secret. Anyone who learns it can reach your login surface. It changes each time the tunnel restarts, which limits how long a leaked address stays useful.

Turning it off

Flip the same toggle. The tunnel stops immediately and the public address stops resolving. Paired devices keep working on your local network.

To remove a device’s access entirely, revoke it under Settings → Devices — that invalidates its token without affecting your other devices.

---

A permanent address (optional)

Quick tunnels mint a new random hostname every restart. That is fine when you pair by QR, since the phone re-learns the address. If you would rather have one that never changes, you can point remote access at a tunnel you own.

You need a domain on Cloudflare. Then:

1. In the Cloudflare dashboard, go to Networking → Tunnels and create a tunnel.
2. Install it as a service using the command the dashboard gives you.
3. Add a route — in the current dashboard this is Routes → Add route → Published application. Older docs call this the Public Hostname tab.
4. Point it at http://127.0.0.1:18781.
5. In Snippbot, open Settings → Remote Access → Advanced and fill in your domain and tunnel token.

The domain does nothing without the token

A pinned hostname only works for a tunnel you created yourself, and the token is what identifies it — it is the long string from the dashboard’s install command. Save a domain with no token and Snippbot falls back to a throwaway tunnel with a random address, quietly ignoring what you typed. The Settings page warns you when it is in that state.

If you already run your own tunnel

You do not have to hand it over. If your daemon is already reachable at a public address — a Cloudflare tunnel running as its own system service, a reverse proxy, Tailscale Funnel — just pair over that address and the app records it:

1. Pair once on your wifi, so the phone learns the local route.
2. Pair again from outside (cellular is easiest), entering your public address and the 6-digit code.

The daemon sees which address each request arrived on and hands the phone back both. Nothing to configure, and it works for any tunnel, not only Cloudflare’s.

Use 127.0.0.1, not localhost

The daemon binds IPv4 only. If you set the route’s origin to localhost, it can resolve to the IPv6 address ::1 and the tunnel will fail with dial tcp [::1]:18781: connect: connection refused — the tunnel looks healthy, but every request errors. Always write 127.0.0.1.

---

Locking it down with Cloudflare Access

By default your public address is a login page anyone can reach. It requires credentials and rate-limits failed attempts, but it is on the internet and will eventually be scanned.

Cloudflare Access removes that: unauthenticated requests are rejected at Cloudflare’s edge and never reach your machine at all.

A browser satisfies Access with an interactive login. The mobile app cannot — it has no browser session — so it presents a service token instead: two headers identifying it as a known machine client.

Setting it up

1. In Zero Trust → Access controls → Service credentials, create a service token. The secret is shown once; copy it immediately.
2. In Integrations → Identity providers, confirm one exists. One-time PIN emails you a code and needs no external provider.
3. In Access controls → Applications, add a self-hosted application for your hostname.
4. Add two policies:
   • Action Allow, Include → Emails → your address. This is the browser path.
   • Action Service Auth, Include → Service token → the one you created. This is the app path.

Service Auth is its own action

The second policy must use the Service Auth action, not Allow. An Allow policy with a service token selector does not grant a machine client access, and the failure looks like a rejected token.

5. In the app, open Settings → Connection → Cloudflare Access and paste the Client ID and Client Secret.

Order matters

Enter the service token in the app before you create the Access application, or pair on your local network first. Once the application exists, every request through the tunnel needs the token — including pairing itself, so a phone that has never paired cannot get in.

Pairing over your LAN never touches Cloudflare and is unaffected.

What to expect when it rejects

Access answers a non-browser client with a redirect to its login page, not a 401. The app detects this and says so plainly; anything else talking to your tunnel — a curl health check, monitoring — will receive an HTML login page instead of the response it expected.

Service tokens also expire. Note the date; when it lapses the app simply stops connecting through the tunnel, with nothing on the daemon side to explain why.

---

Troubleshooting

Symptom	Cause	Fix
Error 1033 or error 530	The tunnel is up but cannot reach your daemon	Check the daemon is running. If you use a custom domain, check the route points at 127.0.0.1:18781, not localhost
Address does not resolve right after enabling	DNS has not propagated yet	Wait up to a minute. Your phone will usually resolve it before your computer does
”cloudflared is not installed”	No tunnel program on PATH	Install it (see Setup) and try again
ngrok shows as unavailable	The channel adapter holds the one free agent session	Use cloudflared, or upgrade your ngrok plan
”This pairing code is no longer valid”	Codes last about a minute and work once	Generate a fresh QR
”Unsupported Link” after scanning with the camera	The installed app predates pairing-link support	Update the Snippbot app, or scan from the app’s own scanner instead
No address shown while remote access is on	The tunnel is not running — only a live tunnel has an address	Check Reopen on restart, or toggle remote access off and on
Tunnel gone after a reboot	It is not set to reopen	Turn on Reopen on restart under Advanced
App works at home, not away	Remote access is off, or the phone only has a local address	Turn remote access on, then re-pair so the phone learns the public address

---

Related

• Mobile connection — how the app finds your daemon
• Devices — reviewing and revoking paired devices
• Channels — the other tunnel, for inbound webhooks