Remote Access
If Vyline must be used outside the LAN, combine Vyline's own remote-access controls with an authenticated network path.
Do not publish it directly to the Internet
Avoid forwarding router traffic directly to Vyline's 3000/tcp. Use a VPN or an authenticated reverse proxy/tunnel instead.
If Vyline is used only from the home LAN or the same device, Cloudflare, Tailscale, WireGuard, and reverse proxies are unnecessary. The options below are for cases where you actually need off-LAN access.
Options
| Method | Good fit | Characteristics |
|---|---|---|
| Cloudflare Tunnel + Access | Browser access | No inbound port; Access adds authentication |
| Tailscale | Your own devices | Private overlay network; no public DNS required |
| WireGuard | Self-managed VPN | Flexible, but you manage routing and keys |
| Reverse proxy | Existing Nginx/Caddy environment | You manage TLS, authentication, and headers |
Vyline settings
VYLINE_LAN_ACCESS=false is the default. To use another LAN device as a subdevice, enable LAN access and use the session issued by UI pairing.
Setting it to true enables a path that treats remote requests as the owner, assuming authentication has already been performed by a trusted proxy/VPN. Use it only when Tailscale ACLs, Cloudflare Access, or an authenticated reverse proxy restrict who can reach Vyline.
If you choose Cloudflare Tunnel
services:
vyline:
image: ghcr.io/tqmane/vyline:latest
networks: [vyline_net]
cloudflared:
image: cloudflare/cloudflared:latest
command: [tunnel, --no-autoupdate, run, --token, ${CLOUDFLARE_TUNNEL_TOKEN}]
depends_on: [vyline]
networks: [vyline_net]
networks:
vyline_net:
driver: bridgeWith Cloudflare Tunnel, the origin is http://vyline:3000. That is a Docker-internal DNS name, not a hostname to enter in a desktop browser. If you choose Tailscale or WireGuard instead, the companion container is unnecessary.
Never commit CLOUDFLARE_TUNNEL_TOKEN, LINE sessions/tokens, data/, storage/, or backup archives to a public repository.