---
title: Reaching your workspace
description: The address people use, HTTPS, the local network and a reverse proxy, and remote access through the tunnel that comes with Pro.
updated: 2026-10-29
canonical: https://turnpanel.com/docs/reaching
markdown: https://turnpanel.com/docs/reaching.md
llms: https://turnpanel.com/llms.txt
---

# Reaching your workspace

The address people use, HTTPS, the local network and a reverse proxy, and remote access through the tunnel that comes with Pro.

## The address

TurnPanel hands out one address for your workspace, and uses it everywhere it makes a link: invitations, notification links, webhook addresses and the MCP address you copy for a space. It picks the first of these that applies.

1. **Your own domain.** If you set one, for example https://turnpanel.example.org.
2. **The tunnel's address.** Otherwise, while the tunnel is on and connected.
3. **The local address.** Otherwise, the address of this machine on your network.


## Settings: Remote access

Settings has a section called Remote access. It tells you which address is in use and why, then shows the tunnel switch and your own domain and HTTPS settings. Links you already sent keep the address they were made with when it changes.


## On your own network

TurnPanel listens on port 7337. By default it listens on this computer only on macOS and Windows, and on every interface on Linux and in Docker. Requests from your own machine or a private network address count as local. Anything else counts as from outside, and that decides how strong sign-in must be (see [People and sign-in](/docs/people-and-sign-in)).

Plain HTTP on a local network is allowed, and TurnPanel says what it costs: no passkeys, shorter sessions, and passwords alone only from inside the network.


## HTTPS

Settings offers what fits your machine, best first.

- **Your own domain, with a certificate TurnPanel gets and renews.** It uses Let's Encrypt and needs port 80 reachable.
- **Tailscale,** when detected, for the machine's .ts.net name.
- **Your own certificate,** or a reverse proxy in front of TurnPanel.
- **Plain HTTP,** on a trusted local network only.


## Behind a reverse proxy

Run TurnPanel on a port only the proxy can reach, and let the proxy handle HTTPS. TurnPanel decides whether a request comes from outside by which door it arrived at, never by a header, so set it up so only your proxy may send forwarded headers.

- **Same machine (best):** point the proxy at TurnPanel's proxy socket, by default `proxy.sock` in the node folder of the data folder. Set `TURNPANEL_PROXY_SOCKET` only if you want it somewhere else. Everything on it counts as from outside.
- **Another machine or a Docker network:** point the proxy at port 7337 and set `TURNPANEL_TRUSTED_PROXIES` to its address.
- Set `TURNPANEL_PUBLIC_URL` to the proxy's address in every case, and make sure WebSockets pass through.
- Tailscale, Cloudflare Tunnel, Traefik and a company VPN work the same way.


## Example: Caddy

Caddy gets its own certificate. With the proxy socket path as shown, this is the whole file.

```caddyfile
turnpanel.example.org {
  reverse_proxy unix//run/turnpanel/proxy.sock
}
```


## The tunnel (Pro)

The tunnel is remote access: an address for your workspace on TurnPanel's tunnel domain, so you can open it from your phone or anywhere else without opening a port or setting up a domain. It is part of Pro and needs a connected TurnPanel account.

Connect your account in Settings under TurnPanel account, then turn on the tunnel in Remote access. Its address appears with Copy and Open. The tunnel is part of TurnPanel's official builds and stops in air-gapped mode. If your plan lapses, the address is kept for a grace period. On a cluster, the tunnel moves to the new front door by itself.

Anything arriving through the tunnel counts as from outside.


## More than one machine

Machines can join into one workspace. One of them is the front door: it serves the interface to the outside and forwards to the others. Its name is the passkey domain, for example turnpanel.example.org.


## Previews and webhooks

A server running in a space, such as an app under development, can be previewed through the front door. Only signed-in people with access to the space can open it. Automation webhooks work only where the front door can be reached.