TL;DR: A working remote access setup for your homelab, with no exposed ports, no dynamic DNS to babysit, and no monthly bill. Full walkthrough uses Twingate's free tier and takes about 20 minutes.

You bought the N100 mini PC. You installed Proxmox, spun up a couple of LXC containers, got Jellyfin running, maybe a Pi-hole, maybe Home Assistant. Everything works beautifully on the couch. Then you leave the house and remember your homelab is a very expensive intranet.

This is the part every $300 build guide skips. Hardware and services are the easy part. The hard part, the part that quietly costs more than the box itself, is reaching your stuff from anywhere without turning your home network into an open target.

The three bad options everyone tries first

Before we get to the setup, it's worth being honest about why the common approaches don't hold up.

Port forwarding

Open port 8096 on your router, point it at Jellyfin, done. Except now Jellyfin is on the public internet, indexed by Shodan within a day, and every vulnerability disclosure against your media server is a race between you patching and someone else scanning. If you have a NAS on the same LAN with SMB shares, one compromised container becomes a much bigger problem. This is the classic homelab mistake and the reason people end up in /r/homelab threads titled "I think I got ransomwared."

Cloudflare Tunnels

Better than port forwarding. The Tunnel is outbound-only, so there's nothing to scan. But you're still publishing services to the public internet on a public hostname, which means you're relying on Cloudflare Access policies (or your own auth layer) to keep strangers out. It's also HTTP-oriented. For SSH, arbitrary TCP, or anything that isn't a web service, you're either paying for Cloudflare's higher tiers or bolting on cloudflared access client wrappers on every device. It works. It's just more moving parts than most homelabs need.

WireGuard

The purist's answer. Fast, clean, self-hosted. Also the answer that requires you to punch a hole in your firewall for the WireGuard port, maintain a dynamic DNS record because your ISP rotates your IP every few weeks, distribute peer configs to every device, and rotate keys yourself. If your ISP puts you behind CGNAT (increasingly common), WireGuard becomes a much harder project involving a VPS relay. Great learning exercise. Bad "I just want to watch my movies" experience.

None of these are bad choices in isolation. But they all charge you a maintenance tax, and that tax compounds every time you add a service.

What we're building instead

The setup below uses Twingate to give you access to everything on your homelab network from any device you sign into, without opening a single inbound port on your router. No dynamic DNS. No public hostnames. No key rotation.

The architecture, in one paragraph: you run a small piece of software called a Connector on any always-on machine inside your homelab (a container works fine). The Connector makes an outbound connection to Twingate's control plane. When you want to reach 192.168.1.50 or jellyfin.home.arpa from your laptop at a coffee shop, the Twingate client on your laptop authenticates you against your identity provider, sets up an encrypted tunnel to the Connector, and proxies your request. Your router sees nothing new. Your services never touch the public internet.

The free tier covers up to 5 users and unlimited resources, which is more than enough for a household or a solo homelab.

Prerequisites

You need:

• A homelab with at least one always-on machine that can run Docker (a Pi 4, a mini PC, an LXC container on Proxmox, whatever you already have)

• A Twingate account (free, and you can sign up with Google, Microsoft, GitHub, or email)

• Client devices you want to connect from (macOS, Windows, Linux, iOS, Android all supported)

• About 20 minutes

You do not need:

• A domain name

• A static IP

• Router access or the ability to forward ports

• Dynamic DNS

• A reverse proxy (though you can keep yours if you already have one)

The last point matters if you're behind CGNAT, on a starter apartment's shared internet, or on a network you don't control. Twingate works without any inbound connectivity because the Connector dials out.

Step 1: Create a Remote Network

First up is creating a Remote Network.

Click Network in the left nav, then Add Remote Network. Give it a name like homelab, leave the location as On Premise, and save.

These are essentially just logical groupings of resource. Think of it as "my house" or "the network the Connector lives on."

Step 2: Deploy a Connector

Inside your new Remote Network, click Deploy Connector. Twingate will generate two tokens (an access token and a refresh token) that the Connector uses to authenticate itself. Copy these somewhere temporary.

The easiest deployment is Docker.

Pull and start the Connector container, replacing the token values with the ones from the admin console:

docker run -d \
  --name twingate-connector \
  --restart unless-stopped \
  --sysctl net.ipv4.ping_group_range="0 2147483647" \
  --env TWINGATE_ACCESS_TOKEN="<your-access-token>" \
  --env TWINGATE_REFRESH_TOKEN="<your-refresh-token>" \
  --env TWINGATE_NETWORK="<your-tenant-name>

Within a few seconds, the Connector status in the admin console should flip to green. If it doesn't, check that the machine has outbound internet access on standard ports, that's the only network requirement.

Running Proxmox? An LXC container works well, or you can use our Proxmox Community Helper Script.

Running on a Pi? Same command, same image. It's multi-arch.

Want redundancy? Deploy a second Connector on a different device in the same Remote Network. Twingate will use both for load balancing and failover. Recommended if you actually rely on the setup.

Step 3: Define your Resources

A Resource in Twingate is anything you want to reach: an IP, a hostname, a subnet, a specific port on a specific machine. This is where the least-privilege part comes in. Instead of "you're on the network, have fun," you're granting access to specific things.

For a homelab, the simplest starting point is to add a Resource for your entire LAN subnet.

In your Remote Network, click Add Resource. In the address field:

• For your whole LAN: 192.168.1.0/24 (adjust to your actual subnet)

• For a single service: 192.168.1.50 or jellyfin.local

• For a specific port only: 192.168.1.50 with a port restriction of 8096/tcp

You can add up to 50 Resources on Twingate's free Starter plan.

For actual least-privilege, add individual Resources per service rather than the whole subnet. It's more clicks up front, and it means a compromised client device can't wander around your LAN. For a personal homelab this is probably overkill; for a shared homelab with family or friends, it's the right call.

Step 4: Install the client and connect

On your laptop, phone, or whatever else you want to connect from, install the Twingate client from the downloads page or your device's app store. Sign in with the same identity you used for the admin console.

That's it. When you try to reach 192.168.1.50 or whatever address you defined as a Resource, the client intercepts the DNS query, sees it matches a Resource you have access to, authenticates you, and routes the connection through the Connector. Everything else on your device continues to use its normal network — Twingate only handles traffic destined for the Resources you've defined. No full-tunnel weirdness, no broken Netflix, no VPN indicator eating your battery.

Step 5: (Optional but recommended) MagicDNS-style names

The Client can resolve internal hostnames if your homelab has a local DNS server (Pi-hole, AdGuard, your router). Add your DNS server as a Resource, and enable DNS resolution in the Resource settings. Now jellyfin.home.arpa works from your phone at the airport the same way it works from your couch.

If you don't run your own DNS, you can just use IP addresses, or add Resources with friendly names like jellyfin that Twingate resolves to the underlying IP.

What you actually get

To summarize what this setup gives you and what it doesn't expose:

Compared to port forwarding, the attack surface visible from the internet drops to nothing. Compared to Cloudflare Tunnels, you're not publishing services to any public hostname. Compared to WireGuard, you don't touch your router, don't distribute peer configs, don't rotate keys, and don't care if your ISP puts you behind CGNAT.

The tradeoff is that you're trusting Twingate's control plane to broker authentication and coordinate connections. Worth noting: the control plane never sees your traffic. When the Client and Connector can't establish a direct peer-to-peer path, traffic falls back through Twingate's Relays, but the tunnel is end-to-end encrypted and the Relays can't decrypt it. This is a reasonable trade for most homelabs. If it isn't for your threat model, self-hosted WireGuard is still there.

Things that trip people up

"Do I need to disable my existing VPN/tunnel?" No. Twingate only routes traffic for defined Resources. Your other network config keeps working.

"What if my Connector machine reboots?" The --restart unless-stopped flag handles it. Connector reconnects on its own.

"Does adding family members count against my 5 users?" Yes. Each person with their own account is a user. Family accounts sharing a single login count as one. Five is enough for most households; if you outgrow it, you can upgrade your plan.

Closing

For a deeper walk-through of Connector deployment options (Kubernetes, systemd, Terraform, cloud marketplace images) and Resource configuration patterns, see the Twingate documentation.

New to Twingate? You can use Twingate for free for up to 5 users, request a personalized demo, or reach out to the team over on the Twingate subreddit.