Stop Treating Your Cloud VPS and Your Home Server Like Two Different Networks
TL;DR: A hybrid homelab shouldn't require hand-rolled WireGuard tunnels between your VPS and your house. Deploy a Twingate Connector at each site and every service becomes reachable by name, whether it's running on the VPS or the Synology in your closet. Docs: Deploying Connectors.
Most serious self-hosters end up with the same shape of network eventually.
There's a box at home doing the actual work: storage, media, maybe a GPU for local LLM inference, definitely a stack of containers your partner has stopped asking about. Then there's a cheap VPS somewhere with a static public IP, terminating your public-facing stuff and holding whatever needs to survive a residential ISP outage.
The two halves are useful. The plumbing between them is not.
If you've built this, you know the routine. A WireGuard tunnel between the VPS and the home router. Manual key exchange. AllowedIPs on both sides. Static routes so the VPS knows how to reach 192.168.1.0/24. A DDNS entry because your home IP rotates every time the ISP feels like it. Firewall rules that made sense in July and are now a mystery in November. When something breaks, you're troubleshooting the tunnel before you can troubleshoot the service you actually cared about.
This post is about getting rid of that entire layer.
The hybrid homelab, briefly
Three topologies cover almost everyone:
VPS as public front door. Home server does the work. The VPS runs Caddy or Nginx and reverse-proxies public traffic back through a tunnel to services at home. Common for people self-hosting a public-facing site alongside a private media stack.
Split by workload. VPS runs anything that needs uptime independent of your home connection: status pages, bots, Git remotes, mail. Home runs anything that needs storage, GPU, or would be absurd to pay cloud egress for.
VPS as jump host. VPS is just an SSH bastion and a WireGuard endpoint. You bounce through it to reach home. It's the cheapest option, and also the one that gets rebuilt from scratch most often because nobody documented it.
All three have the same underlying problem: you're maintaining a private network that spans two administrative domains, and the tools for doing that assume you're either a small business with a fixed IP block or a person who enjoys writing routes.
Why the WireGuard sandwich stops being fun
WireGuard itself is great. The problem isn't the protocol, it's everything you have to build around it to make it useful across a hybrid deployment.
Key management. Every new device or site is a manual keypair exchange and a config edit on both ends.
Dynamic residential IPs. Your home IP changes. WireGuard doesn't rediscover peers, so you're running a DDNS updater and hoping the VPS re-resolves in time. Or you set
PersistentKeepaliveand pretend that's the same as reliability.Routing. You have to think in subnets.
10.0.0.0/24for the tunnel,192.168.1.0/24at home,10.10.0.0/24on the VPS side. Overlaps happen. Split-horizon DNS is its own project.NAT and CGNAT. If your ISP put you behind CGNAT (increasingly common), you can't accept an inbound connection at home at all. Now the VPS has to be the WireGuard server and home has to initiate, which works until it doesn't.
Firewalls. Any inbound port you open on the VPS is a port someone on the internet is scanning right now. You'll see it in the logs if you look.
None of this is hard, exactly. It's just infrastructure you're maintaining to maintain your infrastructure.
What changes with a Connector at each site
Twingate flips this model. Instead of building a tunnel between two networks and then figuring out how to route services across it, you deploy a Connector inside each network and declare which services (Twingate calls them Resources) should be reachable. Every Resource is addressed by its DNS name from any authorized device, regardless of where it physically lives.
The important architectural bits:
Connectors make outbound-only connections to Twingate's Controller and Relays. No inbound firewall rules. No port forwards. CGNAT is irrelevant.
There's no site-to-site tunnel. Each Resource gets its own authenticated, encrypted connection on demand, brokered between the Client on your laptop (or another Connector) and the Connector at the site where the Resource lives.
DNS is handled for you.
jellyfin.home.internalresolves to a CGNAT IP in100.96.0.0/12that only your Client knows about, and only when you're authorized to reach it.Your home IP can rotate every hour. Connectors reconnect outbound. You will not notice.
If you want the deep version, the Twingate architecture docs walk through it. The short version: you stop maintaining a network and start declaring access.
A concrete hybrid setup
Here's the shape I'd build if I were doing this today. Two sites:
Home Remote Network: everything on the LAN behind the home router. Jellyfin, Proxmox, a Synology, Home Assistant, an Ollama box.
VPS Remote Network: a $5/month cloud VM running Docker with a few public-adjacent services (Vaultwarden, a Gitea instance, a status page).
One Connector at each site. Every service exposed as a Resource. Access policies tied to your identity provider (Google, GitHub, whatever you already use for SSO).
Deploy the home Connector
The Connector runs anywhere with outbound internet. I'd put it in a container on whatever's already running Docker at home.
Pull and run the Connector container using the tokens generated in the Twingate admin console:
docker run -d \ --name twingate-connector-home \ --restart unless-stopped \ --sysctl net.ipv4.ping_group_range="0 2147483647" \ -e TWINGATE_NETWORK="yournetwork" \ -e TWINGATE_ACCESS_TOKEN="<access-token>" \ -e TWINGATE_REFRESH_TOKEN="<refresh-token>
Within a minute the Connector shows as online in the admin console. No port forwards. No firewall changes. You didn't touch your router.
Deploy the VPS Connector
Same container, different host. On a Debian/Ubuntu VPS you can run it directly under Docker or via the systemd installer. Docker is fine:
docker run -d \ --name twingate-connector-vps \ --restart unless-stopped \ --sysctl net.ipv4.ping_group_range="0 2147483647" \ -e TWINGATE_NETWORK="yournetwork" \ -e TWINGATE_ACCESS_TOKEN="<vps-access-token>" \ -e TWINGATE_REFRESH_TOKEN="<vps-refresh-token>
Two Connectors, two Remote Networks, zero tunnels between them.
Add Resources
In the admin console, create a Resource under the Home network for each service you want reachable. Give it the DNS name it already has on your LAN (or a name you're inventing right now):
jellyfin.home.internal→ home Connectorproxmox.home.internal:8006→ home Connectorha.home.internal→ home Connectorollama.home.internal:11434→ home Connector
Do the same under the VPS network:
gitea.vps.internal:3000→ VPS Connectorvault.vps.internal→ VPS Connector
Assign a policy that lets your user (or a group) reach them. That's the whole configuration.
Reach everything from your laptop
Install the Twingate Client. Sign in with your IdP. From that point, jellyfin.home.internal in your browser just works. So does ssh proxmox.home.internal. So does git clone git@gitea.vps.internal:me/dotfiles.git. Your laptop doesn't care which side of the split each service lives on. Neither should you.
What about VPS-to-home traffic?
This is the part most people expect to still need a tunnel for. You don't.
Say your VPS-hosted Gitea needs to push backups to a MinIO bucket running at home. Traditionally you'd route that over the site-to-site WireGuard link. With Twingate you can install a Connector-adjacent Client on the VPS itself (Twingate supports headless Linux Clients) and access the home MinIO Resource by name from the VPS, subject to the same access policy as any other client. The path is outbound from both sides, brokered through Twingate's control plane, and never touches an open port.
For most homelab traffic patterns, though, the honest answer is: you probably don't need constant VPS-to-home connectivity. What you actually need is a specific service on one side to reach a specific service on the other, occasionally. That's what Resources model well.
What you gave up
Fair to name the tradeoffs.
You now depend on Twingate's Controller to broker new connections. Existing tunnels stay up if the Controller is briefly unreachable, but a full outage means no new authorizations. In practice this has been extremely reliable, and Twingate has a public post-mortem culture worth reading if you're the kind of person who cares about that (which, if you're reading this, you probably are).
You're trusting a SaaS control plane with your access policy. The Controller never sees your traffic — Connectors independently verify every authorization and the data plane is E2E encrypted — but the policy itself lives with Twingate. If that's a dealbreaker for you philosophically, this isn't the tool.
The free tier caps at 5 users. For a household homelab that's plenty. For a shared homelab with a dozen friends, you're on a paid plan.
What you got back: no key management, no port forwards, no DDNS, no static routes, no residential IP anxiety, no CGNAT workarounds, no firewall rules to audit next January. Your VPS and your home server behave like one network because you stopped trying to make them one network.
When this scales past homelab
The same pattern lands cleanly in a small enterprise or startup setup: Connector in each VPC, Connector in each office, Resources declared per service, access policies tied to your IdP. The homelab version and the production version are the same architecture with different labels on the boxes. Which is, I think, the point — you shouldn't need one mental model for your home network and another for work.
Closing
Full setup details, Connector deployment options (Docker, systemd, Helm, Terraform), and Resource configuration are in 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.
Rapidly implement a modern Zero Trust network that is more secure and maintainable than VPNs.
Stop Treating Your Cloud VPS and Your Home Server Like Two Different Networks
TL;DR: A hybrid homelab shouldn't require hand-rolled WireGuard tunnels between your VPS and your house. Deploy a Twingate Connector at each site and every service becomes reachable by name, whether it's running on the VPS or the Synology in your closet. Docs: Deploying Connectors.
Most serious self-hosters end up with the same shape of network eventually.
There's a box at home doing the actual work: storage, media, maybe a GPU for local LLM inference, definitely a stack of containers your partner has stopped asking about. Then there's a cheap VPS somewhere with a static public IP, terminating your public-facing stuff and holding whatever needs to survive a residential ISP outage.
The two halves are useful. The plumbing between them is not.
If you've built this, you know the routine. A WireGuard tunnel between the VPS and the home router. Manual key exchange. AllowedIPs on both sides. Static routes so the VPS knows how to reach 192.168.1.0/24. A DDNS entry because your home IP rotates every time the ISP feels like it. Firewall rules that made sense in July and are now a mystery in November. When something breaks, you're troubleshooting the tunnel before you can troubleshoot the service you actually cared about.
This post is about getting rid of that entire layer.
The hybrid homelab, briefly
Three topologies cover almost everyone:
VPS as public front door. Home server does the work. The VPS runs Caddy or Nginx and reverse-proxies public traffic back through a tunnel to services at home. Common for people self-hosting a public-facing site alongside a private media stack.
Split by workload. VPS runs anything that needs uptime independent of your home connection: status pages, bots, Git remotes, mail. Home runs anything that needs storage, GPU, or would be absurd to pay cloud egress for.
VPS as jump host. VPS is just an SSH bastion and a WireGuard endpoint. You bounce through it to reach home. It's the cheapest option, and also the one that gets rebuilt from scratch most often because nobody documented it.
All three have the same underlying problem: you're maintaining a private network that spans two administrative domains, and the tools for doing that assume you're either a small business with a fixed IP block or a person who enjoys writing routes.
Why the WireGuard sandwich stops being fun
WireGuard itself is great. The problem isn't the protocol, it's everything you have to build around it to make it useful across a hybrid deployment.
Key management. Every new device or site is a manual keypair exchange and a config edit on both ends.
Dynamic residential IPs. Your home IP changes. WireGuard doesn't rediscover peers, so you're running a DDNS updater and hoping the VPS re-resolves in time. Or you set
PersistentKeepaliveand pretend that's the same as reliability.Routing. You have to think in subnets.
10.0.0.0/24for the tunnel,192.168.1.0/24at home,10.10.0.0/24on the VPS side. Overlaps happen. Split-horizon DNS is its own project.NAT and CGNAT. If your ISP put you behind CGNAT (increasingly common), you can't accept an inbound connection at home at all. Now the VPS has to be the WireGuard server and home has to initiate, which works until it doesn't.
Firewalls. Any inbound port you open on the VPS is a port someone on the internet is scanning right now. You'll see it in the logs if you look.
None of this is hard, exactly. It's just infrastructure you're maintaining to maintain your infrastructure.
What changes with a Connector at each site
Twingate flips this model. Instead of building a tunnel between two networks and then figuring out how to route services across it, you deploy a Connector inside each network and declare which services (Twingate calls them Resources) should be reachable. Every Resource is addressed by its DNS name from any authorized device, regardless of where it physically lives.
The important architectural bits:
Connectors make outbound-only connections to Twingate's Controller and Relays. No inbound firewall rules. No port forwards. CGNAT is irrelevant.
There's no site-to-site tunnel. Each Resource gets its own authenticated, encrypted connection on demand, brokered between the Client on your laptop (or another Connector) and the Connector at the site where the Resource lives.
DNS is handled for you.
jellyfin.home.internalresolves to a CGNAT IP in100.96.0.0/12that only your Client knows about, and only when you're authorized to reach it.Your home IP can rotate every hour. Connectors reconnect outbound. You will not notice.
If you want the deep version, the Twingate architecture docs walk through it. The short version: you stop maintaining a network and start declaring access.
A concrete hybrid setup
Here's the shape I'd build if I were doing this today. Two sites:
Home Remote Network: everything on the LAN behind the home router. Jellyfin, Proxmox, a Synology, Home Assistant, an Ollama box.
VPS Remote Network: a $5/month cloud VM running Docker with a few public-adjacent services (Vaultwarden, a Gitea instance, a status page).
One Connector at each site. Every service exposed as a Resource. Access policies tied to your identity provider (Google, GitHub, whatever you already use for SSO).
Deploy the home Connector
The Connector runs anywhere with outbound internet. I'd put it in a container on whatever's already running Docker at home.
Pull and run the Connector container using the tokens generated in the Twingate admin console:
docker run -d \ --name twingate-connector-home \ --restart unless-stopped \ --sysctl net.ipv4.ping_group_range="0 2147483647" \ -e TWINGATE_NETWORK="yournetwork" \ -e TWINGATE_ACCESS_TOKEN="<access-token>" \ -e TWINGATE_REFRESH_TOKEN="<refresh-token>
Within a minute the Connector shows as online in the admin console. No port forwards. No firewall changes. You didn't touch your router.
Deploy the VPS Connector
Same container, different host. On a Debian/Ubuntu VPS you can run it directly under Docker or via the systemd installer. Docker is fine:
docker run -d \ --name twingate-connector-vps \ --restart unless-stopped \ --sysctl net.ipv4.ping_group_range="0 2147483647" \ -e TWINGATE_NETWORK="yournetwork" \ -e TWINGATE_ACCESS_TOKEN="<vps-access-token>" \ -e TWINGATE_REFRESH_TOKEN="<vps-refresh-token>
Two Connectors, two Remote Networks, zero tunnels between them.
Add Resources
In the admin console, create a Resource under the Home network for each service you want reachable. Give it the DNS name it already has on your LAN (or a name you're inventing right now):
jellyfin.home.internal→ home Connectorproxmox.home.internal:8006→ home Connectorha.home.internal→ home Connectorollama.home.internal:11434→ home Connector
Do the same under the VPS network:
gitea.vps.internal:3000→ VPS Connectorvault.vps.internal→ VPS Connector
Assign a policy that lets your user (or a group) reach them. That's the whole configuration.
Reach everything from your laptop
Install the Twingate Client. Sign in with your IdP. From that point, jellyfin.home.internal in your browser just works. So does ssh proxmox.home.internal. So does git clone git@gitea.vps.internal:me/dotfiles.git. Your laptop doesn't care which side of the split each service lives on. Neither should you.
What about VPS-to-home traffic?
This is the part most people expect to still need a tunnel for. You don't.
Say your VPS-hosted Gitea needs to push backups to a MinIO bucket running at home. Traditionally you'd route that over the site-to-site WireGuard link. With Twingate you can install a Connector-adjacent Client on the VPS itself (Twingate supports headless Linux Clients) and access the home MinIO Resource by name from the VPS, subject to the same access policy as any other client. The path is outbound from both sides, brokered through Twingate's control plane, and never touches an open port.
For most homelab traffic patterns, though, the honest answer is: you probably don't need constant VPS-to-home connectivity. What you actually need is a specific service on one side to reach a specific service on the other, occasionally. That's what Resources model well.
What you gave up
Fair to name the tradeoffs.
You now depend on Twingate's Controller to broker new connections. Existing tunnels stay up if the Controller is briefly unreachable, but a full outage means no new authorizations. In practice this has been extremely reliable, and Twingate has a public post-mortem culture worth reading if you're the kind of person who cares about that (which, if you're reading this, you probably are).
You're trusting a SaaS control plane with your access policy. The Controller never sees your traffic — Connectors independently verify every authorization and the data plane is E2E encrypted — but the policy itself lives with Twingate. If that's a dealbreaker for you philosophically, this isn't the tool.
The free tier caps at 5 users. For a household homelab that's plenty. For a shared homelab with a dozen friends, you're on a paid plan.
What you got back: no key management, no port forwards, no DDNS, no static routes, no residential IP anxiety, no CGNAT workarounds, no firewall rules to audit next January. Your VPS and your home server behave like one network because you stopped trying to make them one network.
When this scales past homelab
The same pattern lands cleanly in a small enterprise or startup setup: Connector in each VPC, Connector in each office, Resources declared per service, access policies tied to your IdP. The homelab version and the production version are the same architecture with different labels on the boxes. Which is, I think, the point — you shouldn't need one mental model for your home network and another for work.
Closing
Full setup details, Connector deployment options (Docker, systemd, Helm, Terraform), and Resource configuration are in 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.
Rapidly implement a modern Zero Trust network that is more secure and maintainable than VPNs.
Stop Treating Your Cloud VPS and Your Home Server Like Two Different Networks
TL;DR: A hybrid homelab shouldn't require hand-rolled WireGuard tunnels between your VPS and your house. Deploy a Twingate Connector at each site and every service becomes reachable by name, whether it's running on the VPS or the Synology in your closet. Docs: Deploying Connectors.
Most serious self-hosters end up with the same shape of network eventually.
There's a box at home doing the actual work: storage, media, maybe a GPU for local LLM inference, definitely a stack of containers your partner has stopped asking about. Then there's a cheap VPS somewhere with a static public IP, terminating your public-facing stuff and holding whatever needs to survive a residential ISP outage.
The two halves are useful. The plumbing between them is not.
If you've built this, you know the routine. A WireGuard tunnel between the VPS and the home router. Manual key exchange. AllowedIPs on both sides. Static routes so the VPS knows how to reach 192.168.1.0/24. A DDNS entry because your home IP rotates every time the ISP feels like it. Firewall rules that made sense in July and are now a mystery in November. When something breaks, you're troubleshooting the tunnel before you can troubleshoot the service you actually cared about.
This post is about getting rid of that entire layer.
The hybrid homelab, briefly
Three topologies cover almost everyone:
VPS as public front door. Home server does the work. The VPS runs Caddy or Nginx and reverse-proxies public traffic back through a tunnel to services at home. Common for people self-hosting a public-facing site alongside a private media stack.
Split by workload. VPS runs anything that needs uptime independent of your home connection: status pages, bots, Git remotes, mail. Home runs anything that needs storage, GPU, or would be absurd to pay cloud egress for.
VPS as jump host. VPS is just an SSH bastion and a WireGuard endpoint. You bounce through it to reach home. It's the cheapest option, and also the one that gets rebuilt from scratch most often because nobody documented it.
All three have the same underlying problem: you're maintaining a private network that spans two administrative domains, and the tools for doing that assume you're either a small business with a fixed IP block or a person who enjoys writing routes.
Why the WireGuard sandwich stops being fun
WireGuard itself is great. The problem isn't the protocol, it's everything you have to build around it to make it useful across a hybrid deployment.
Key management. Every new device or site is a manual keypair exchange and a config edit on both ends.
Dynamic residential IPs. Your home IP changes. WireGuard doesn't rediscover peers, so you're running a DDNS updater and hoping the VPS re-resolves in time. Or you set
PersistentKeepaliveand pretend that's the same as reliability.Routing. You have to think in subnets.
10.0.0.0/24for the tunnel,192.168.1.0/24at home,10.10.0.0/24on the VPS side. Overlaps happen. Split-horizon DNS is its own project.NAT and CGNAT. If your ISP put you behind CGNAT (increasingly common), you can't accept an inbound connection at home at all. Now the VPS has to be the WireGuard server and home has to initiate, which works until it doesn't.
Firewalls. Any inbound port you open on the VPS is a port someone on the internet is scanning right now. You'll see it in the logs if you look.
None of this is hard, exactly. It's just infrastructure you're maintaining to maintain your infrastructure.
What changes with a Connector at each site
Twingate flips this model. Instead of building a tunnel between two networks and then figuring out how to route services across it, you deploy a Connector inside each network and declare which services (Twingate calls them Resources) should be reachable. Every Resource is addressed by its DNS name from any authorized device, regardless of where it physically lives.
The important architectural bits:
Connectors make outbound-only connections to Twingate's Controller and Relays. No inbound firewall rules. No port forwards. CGNAT is irrelevant.
There's no site-to-site tunnel. Each Resource gets its own authenticated, encrypted connection on demand, brokered between the Client on your laptop (or another Connector) and the Connector at the site where the Resource lives.
DNS is handled for you.
jellyfin.home.internalresolves to a CGNAT IP in100.96.0.0/12that only your Client knows about, and only when you're authorized to reach it.Your home IP can rotate every hour. Connectors reconnect outbound. You will not notice.
If you want the deep version, the Twingate architecture docs walk through it. The short version: you stop maintaining a network and start declaring access.
A concrete hybrid setup
Here's the shape I'd build if I were doing this today. Two sites:
Home Remote Network: everything on the LAN behind the home router. Jellyfin, Proxmox, a Synology, Home Assistant, an Ollama box.
VPS Remote Network: a $5/month cloud VM running Docker with a few public-adjacent services (Vaultwarden, a Gitea instance, a status page).
One Connector at each site. Every service exposed as a Resource. Access policies tied to your identity provider (Google, GitHub, whatever you already use for SSO).
Deploy the home Connector
The Connector runs anywhere with outbound internet. I'd put it in a container on whatever's already running Docker at home.
Pull and run the Connector container using the tokens generated in the Twingate admin console:
docker run -d \ --name twingate-connector-home \ --restart unless-stopped \ --sysctl net.ipv4.ping_group_range="0 2147483647" \ -e TWINGATE_NETWORK="yournetwork" \ -e TWINGATE_ACCESS_TOKEN="<access-token>" \ -e TWINGATE_REFRESH_TOKEN="<refresh-token>
Within a minute the Connector shows as online in the admin console. No port forwards. No firewall changes. You didn't touch your router.
Deploy the VPS Connector
Same container, different host. On a Debian/Ubuntu VPS you can run it directly under Docker or via the systemd installer. Docker is fine:
docker run -d \ --name twingate-connector-vps \ --restart unless-stopped \ --sysctl net.ipv4.ping_group_range="0 2147483647" \ -e TWINGATE_NETWORK="yournetwork" \ -e TWINGATE_ACCESS_TOKEN="<vps-access-token>" \ -e TWINGATE_REFRESH_TOKEN="<vps-refresh-token>
Two Connectors, two Remote Networks, zero tunnels between them.
Add Resources
In the admin console, create a Resource under the Home network for each service you want reachable. Give it the DNS name it already has on your LAN (or a name you're inventing right now):
jellyfin.home.internal→ home Connectorproxmox.home.internal:8006→ home Connectorha.home.internal→ home Connectorollama.home.internal:11434→ home Connector
Do the same under the VPS network:
gitea.vps.internal:3000→ VPS Connectorvault.vps.internal→ VPS Connector
Assign a policy that lets your user (or a group) reach them. That's the whole configuration.
Reach everything from your laptop
Install the Twingate Client. Sign in with your IdP. From that point, jellyfin.home.internal in your browser just works. So does ssh proxmox.home.internal. So does git clone git@gitea.vps.internal:me/dotfiles.git. Your laptop doesn't care which side of the split each service lives on. Neither should you.
What about VPS-to-home traffic?
This is the part most people expect to still need a tunnel for. You don't.
Say your VPS-hosted Gitea needs to push backups to a MinIO bucket running at home. Traditionally you'd route that over the site-to-site WireGuard link. With Twingate you can install a Connector-adjacent Client on the VPS itself (Twingate supports headless Linux Clients) and access the home MinIO Resource by name from the VPS, subject to the same access policy as any other client. The path is outbound from both sides, brokered through Twingate's control plane, and never touches an open port.
For most homelab traffic patterns, though, the honest answer is: you probably don't need constant VPS-to-home connectivity. What you actually need is a specific service on one side to reach a specific service on the other, occasionally. That's what Resources model well.
What you gave up
Fair to name the tradeoffs.
You now depend on Twingate's Controller to broker new connections. Existing tunnels stay up if the Controller is briefly unreachable, but a full outage means no new authorizations. In practice this has been extremely reliable, and Twingate has a public post-mortem culture worth reading if you're the kind of person who cares about that (which, if you're reading this, you probably are).
You're trusting a SaaS control plane with your access policy. The Controller never sees your traffic — Connectors independently verify every authorization and the data plane is E2E encrypted — but the policy itself lives with Twingate. If that's a dealbreaker for you philosophically, this isn't the tool.
The free tier caps at 5 users. For a household homelab that's plenty. For a shared homelab with a dozen friends, you're on a paid plan.
What you got back: no key management, no port forwards, no DDNS, no static routes, no residential IP anxiety, no CGNAT workarounds, no firewall rules to audit next January. Your VPS and your home server behave like one network because you stopped trying to make them one network.
When this scales past homelab
The same pattern lands cleanly in a small enterprise or startup setup: Connector in each VPC, Connector in each office, Resources declared per service, access policies tied to your IdP. The homelab version and the production version are the same architecture with different labels on the boxes. Which is, I think, the point — you shouldn't need one mental model for your home network and another for work.
Closing
Full setup details, Connector deployment options (Docker, systemd, Helm, Terraform), and Resource configuration are in 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.
Solutions
Solutions
The VPN replacement your workforce will love.
Solutions