Remote access for local LLMs — security comparison

Your model runs on your hardware. You need to reach it from somewhere else — another machine, a teammate’s laptop, or a hosted coding agent. This page compares 4 methods for doing that securely, with honest trade-offs for each.

Quick verdict

Method	Open inbound ports	Works behind CGNAT	Auth built in	Setup time	Best for
SSH tunnel	No	No	OS credentials only	5 minutes	Solo dev, quick test
Tailscale	No	Yes	Tailnet identity	10 minutes	Personal device mesh
Cloudflare Tunnel	No	Yes	Your own layer	15 minutes	Public web app behind edge
Tokios connector	No	Yes	`sk-tok-…` API keys	2 minutes	Exposing a local model API

All 4 methods avoid opening an inbound port. They differ in who can call the endpoint, how authentication works, and whether they were designed for an API workload.

Threat model for local LLM APIs

Before comparing methods, here’s what can go wrong when you expose a local inference server:

Threat	Impact	Likelihood without auth
Unauthorized inference calls	GPU cost, data leakage	High — scanners index open endpoints within hours
Model weight exfiltration	IP theft	Medium — requires API access to `/v1/models` or pull endpoints
Prompt injection via shared endpoint	Misuse of your compute	Medium — multi-tenant without per-user keys
Man-in-the-middle on unencrypted tunnel	Credential theft	Low — all 4 methods below use TLS
Denial of service	GPU saturation	Medium — no rate limiting on bare backends

The key principle: a local model API has no built-in user management. Ollama, vLLM, llama.cpp, and LM Studio all expose unauthenticated endpoints by default. Authentication must come from whatever sits in front.

Method 1: SSH tunnels

SSH tunnels forward a local port over an encrypted SSH session. They’re the oldest method here and the most manual.

How it works

ssh -L 8000:127.0.0.1:8000 user@your-server-ip

You SSH into the machine and forward port 8000 to your local machine. While the tunnel is open, you call http://localhost:8000 as if the model were local.

Security properties

Encryption: SSH provides strong encryption.
Authentication: OS-level credentials (password or key pair).
Access scope: Whoever holds the SSH key gets full shell access to the machine — not just the API port.

The catch for LLM use

SSH requires a stable public IP or a jump host. CGNAT blocks it entirely.
Tunnels drop on network changes and don’t reconnect automatically.
Each user needs their own tunnel and their own SSH credentials — there’s no concept of a scoped API key.
No built-in streaming support. Your client needs to handle reconnects on its own.

When to use it

SSH tunnels work for a solo developer testing something quickly. They don’t scale to teammates, agents, or anything that needs to run unattended.

Method 2: Tailscale

Tailscale creates a zero-trust mesh network (a “tailnet”) between your devices. Each device gets a stable IP, and traffic flows over encrypted WireGuard.

How it works

# Install Tailscale on the model server
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

# Access the model at the Tailscale IP from any tailnet device
curl http://100.x.y.z:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "llama3", "messages": [{"role": "user", "content": "Hello!"}]}'

Security properties

Encryption: WireGuard with per-device keys.
Authentication: Device identity verified by the Tailscale coordination server.
Access scope: Only devices you’ve added to your tailnet can reach the model.

The catch for LLM use

Every caller must join your tailnet first. That works for your own devices but doesn’t fit teammates, SaaS clients, or coding agents that need an API key — not a VPN.
Tailscale Funnel can publish a service publicly, but it’s restricted to ports 443, 8443, and 10000. Bandwidth is limited and not configurable.
No API key management — you manage device access, not per-request authentication.
The model server still has no auth layer. Anyone on the tailnet can call it with no credential.

When to use it

Tailscale is excellent for personal multi-device access — your laptop reaching your home server, for example. It’s the right tool when you control every device and don’t need to hand out API keys.

Method 3: Cloudflare Tunnel

Cloudflare Tunnel (cloudflared) routes traffic through Cloudflare’s edge network with no inbound port required. It acts as a reverse proxy.

How it works

# cloudflared config.yml
tunnel: ct-tok-XXXX
credentials-file: /etc/cloudflared/creds.json

ingress:
  - hostname: llm.example.com
    service: http://127.0.0.1:8000
  - service: http_status:404

cloudflared tunnel run llm-tunnel

Security properties

Encryption: TLS from client to Cloudflare edge, then Cloudflare to your origin.
Authentication: You build it — Cloudflare Access, API tokens, or your own middleware.
Access scope: Publicly routable by default. You add auth on top.

The catch for LLM use

Buffering: Cloudflare buffers responses by default unless the response carries a text/event-stream content-type header. SSE streaming can break or lag behind.
Proxy timeouts: Cloudflare’s proxy timeouts are around 100 seconds on the free tier. Long generations (large context, high max_tokens) can get cut off mid-stream.
No API key layer: You need to add authentication yourself — Cloudflare Access, a middleware, or an API gateway in front.
Complexity: DNS records, Cloudflare Access policies, and tunnel lifecycle management add up.

When to use it

Cloudflare Tunnel fits when you’re publishing a web application behind Cloudflare’s edge and already use their ecosystem. For a raw inference API, the buffering and timeout behavior make it a poor fit without significant tuning.

Method 4: Tokios connector

The Tokios connector is purpose-built for one task: turning a local model endpoint into an authenticated API reachable from anywhere.

How it works

Install the connector on the model server

Windows

irm https://tokios.com/downloads/install/windows | iex; tokios-install -Code 'TKS-XXXX-XXXX'

macOS

curl -fsSL https://tokios.com/downloads/install/macos | sh -s -- --code TKS-XXXX-XXXX

Linux

curl -fsSL https://tokios.com/downloads/install/linux | sh -s -- --code TKS-XXXX-XXXX

In the Tokios dashboard, register your model with a public name (for example, llama3-tunnel), then create a sk-tok-… key scoped to it.

Call from anywhere

curl https://api.tokios.com/v1/chat/completions \
  -H "Authorization: Bearer sk-tok-YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "llama3-tunnel", "messages": [{"role": "user", "content": "Hello!"}]}'

Security properties

Encryption: TLS from client to api.tokios.com, then TLS over the outbound tunnel to your machine.
Authentication: Per-request bearer token (sk-tok-…) with optional model-name scoping.
Access scope: Each API key can be scoped to specific deployments. Revoking a key cuts access immediately without touching the connector or the backend.

Architecture

The connector only dials out to https://api.tokios.com. No inbound port is opened on your machine. No DNS record, no public IP, no port forwarding.

Your machine                    api.tokios.com              Caller
─────────────                   ──────────────              ──────
vLLM/Ollama ─┐                                            sk-tok-… key
  (localhost) ├─ connector ──── outbound tunnel ────►  gateway ──► HTTPS request
             └─ no inbound     (initiates connection)    (auth +
                port open                                routing)

When to use it

Tokios fits when you need to:

Share model access with teammates using per-person API keys.
Connect coding agents (Claude Code, Codex, Cline) that expect a standard OpenAI or Anthropic base URL.
Work behind CGNAT, corporate NAT, or any network where inbound connections are blocked.
Avoid building and maintaining your own auth layer.

Comparison matrix

Property	SSH tunnel	Tailscale	Cloudflare Tunnel	Tokios connector
Inbound port open	No	No	No	No
Works behind CGNAT	No	Yes	Yes	Yes
Authentication	SSH key (full shell)	Device identity (tailnet)	You build it	`sk-tok-…` API keys
Per-user key scoping	No	No	Requires Access	Yes — per deployment
SSE streaming	Manual reconnect	Yes	Buffered by default	Native SSE
Long generation support	Yes	Yes	~100s timeout	No limit
OpenAI/Anthropic compat	No — raw port	No — raw port	No — raw port	Yes — both APIs
Setup complexity	Low (1 command)	Medium (install + join)	High (DNS + config + Access)	Low (1 command + dashboard)
Reconnect on network change	No	Yes (WireGuard)	Yes	Yes
Multi-user from day 1	No	No (each joins tailnet)	Possible with Access	Yes — create keys
Designed for model APIs	No	No	No	Yes

Recommendation by use case

Use case	Recommended method	Why
Quick test from your laptop	SSH tunnel	1 command, nothing to install
Personal multi-device access	Tailscale	WireGuard mesh, stable IPs, zero config after setup
Public web app behind CDN	Cloudflare Tunnel	Edge caching, DDoS protection, fits web traffic
Share model with teammates	Tokios connector	Per-person API keys, no VPN, scoped access
Connect a coding agent	Tokios connector	Standard OpenAI/Anthropic base URL, streaming
Behind CGNAT or corporate NAT	Tokios connector or Tailscale	Both work without a public IP
Production API for multiple users	Tokios connector	Auth, key rotation, and streaming built in

These methods aren’t mutually exclusive. You can run Tailscale for personal device access and Tokios for teammate or agent access on the same machine — they don’t conflict.

What about just opening the port?

Setting OLLAMA_HOST=0.0.0.0, forwarding a router port, or binding vLLM to 0.0.0.0 makes the model reachable — with no authentication at all. Security researchers reported roughly 175,000 exposed Ollama hosts on the open internet (SentinelLABS/Censys, 2026). Internet-wide scanners index exposed services within hours. None of the 4 methods above require you to open an inbound port, and none should be skipped in favor of binding wider.

Your model stays local — your endpoint works everywhere

Whichever method you choose, the principle is the same: your model never leaves your machine, and the endpoint is what you choose to expose. Tokios makes the “expose it securely to multiple users” path the shortest one.

Deep dives

Each comparison below goes beyond the table above — covering architecture, failure modes, and the specific workload constraints that make one approach beat another:

Tokios vs Tailscale

Device mesh vs API gateway: when peer-to-peer WireGuard is enough and when you need scoped API keys.

Tokios vs Cloudflare Tunnel

SSE buffering, proxy timeouts, and why Cloudflare’s edge can silently break streaming inference.

Tokios vs LiteLLM

Open-source multi-provider proxy vs managed tunnel — and how to stack both together.

Tokios vs DIY stack

The 7-layer self-hosted stack (runtime, proxy, tunnel, auth, TLS, DNS, monitoring) and when building it yourself is worth the hours.

When to use Tokios

A decision framework: CGNAT, team size, agent compatibility, and airgap requirements — which tool fits which constraint.

Quickstart

Pair a connector and register your first model in 2 minutes.

Why outbound-only

The architecture decision and what it eliminates.

vLLM remote access

Step-by-step guide for exposing a local vLLM server.

Hardening checklist

10 steps to secure a self-hosted LLM deployment.

​Quick verdict

​Threat model for local LLM APIs

​Method 1: SSH tunnels

​How it works

​Security properties

​The catch for LLM use

​When to use it

​Method 2: Tailscale

​How it works

​Security properties

​The catch for LLM use

​When to use it

​Method 3: Cloudflare Tunnel

​How it works

​Security properties

​The catch for LLM use

​When to use it

​Method 4: Tokios connector

​How it works

​Security properties

​Architecture

​When to use it

​Comparison matrix

​Recommendation by use case

​What about just opening the port?

​Your model stays local — your endpoint works everywhere

​Deep dives

Tokios vs Tailscale

Tokios vs Cloudflare Tunnel

Tokios vs LiteLLM

Tokios vs DIY stack

When to use Tokios

Quickstart

Why outbound-only

vLLM remote access

Hardening checklist

Quick verdict

Threat model for local LLM APIs

Method 1: SSH tunnels

How it works

Security properties

The catch for LLM use

When to use it

Method 2: Tailscale

How it works

Security properties

The catch for LLM use

When to use it

Method 3: Cloudflare Tunnel

How it works

Security properties

The catch for LLM use

When to use it

Method 4: Tokios connector

How it works

Security properties

Architecture

When to use it

Comparison matrix

Recommendation by use case

What about just opening the port?

Your model stays local — your endpoint works everywhere

Deep dives