Use one Docker VPN gateway for selected NAS applications while keeping storage, Plex and private administration independent.
Gluetun is a clean container VPN gateway
Gluetun works best when selected Docker applications share its network namespace and firewall. It gives NAS owners a portable provider-VPN pattern without changing the route of the entire server.
How should you deploy Gluetun?
Select the outcome you actually need. The right architecture changes when the goal is private remote access, outbound privacy, container isolation or Plex stability.
Building a Docker NAS? Current Amazon NAS listings
Compare current NAS enclosures for Gluetun, downloaders, media applications and other persistent containers.
Prices and availability are pulled from Cloudzat’s existing Amazon catalogue and can change. As an Amazon Associate, Cloudzat earns from qualifying purchases.
What Gluetun does on a NAS
Gluetun is a Docker VPN client and gateway. Instead of installing a provider VPN across the entire NAS operating system, you run Gluetun as one container and make selected applications share its network namespace. The gateway establishes the encrypted tunnel, controls DNS and applies firewall rules. Applications attached to it inherit that network path. This makes Gluetun particularly useful for NAS owners who want qBittorrent, a scraper or another outbound workload behind a VPN without changing the route used by Plex, SMB, backups or the NAS management interface.
The architecture is portable. The same basic pattern can run on a Linux Docker host, Unraid, a Docker-capable Synology or other NAS platforms that support the required container features. Platform-specific interfaces differ, but the traffic model remains the same: one VPN gateway, several optional dependent containers, and the rest of the host untouched.
Choose the provider before you write the Compose file
Gluetun supports many VPN providers, but providers do not expose identical features. Some support WireGuard and OpenVPN, some only one method in a particular Gluetun integration, and port-forwarding support varies substantially. Select the provider based on the application requirement rather than simply choosing the lowest subscription price.
Surfshark works well for ordinary outbound Docker traffic and Gluetun supports both OpenVPN and WireGuard for it. NordVPN also has Gluetun support. Proton VPN and PIA are notable when provider-side port forwarding matters because Gluetun has specific port-forwarding integrations for supported services. Recheck current Gluetun and provider documentation before deployment because credentials and feature policies can change.
WireGuard is usually the first protocol to test
WireGuard is a natural default for modern container VPN stacks because it has low overhead and a relatively simple configuration model. Gluetun has native WireGuard integrations for several major providers, including Surfshark and NordVPN. The provider may supply a private key, WireGuard address or configuration that must be translated into Gluetun environment variables.
OpenVPN remains valuable when the provider's WireGuard credentials are harder to obtain or when a specific network behaves better with OpenVPN. Do not switch protocols only because one benchmark is faster. Verify stability, DNS, reconnect behavior and compatibility with the provider account. A tunnel that automatically recovers after a router or NAS reboot is more valuable than one that wins a short speed test but needs manual repair.
Attach containers to Gluetun correctly
In the same Compose project, Gluetun's documentation uses `network_mode: "service:gluetun"` for an application that should share the gateway. For a separately managed container, the equivalent can be `network_mode: "container:gluetun"`. Once you do this, the attached application no longer has its own independent Docker network namespace. Its internet traffic and exposed ports are controlled through Gluetun.
This is why ordinary Docker networking examples can stop working after the change. A service that previously mapped its own port must now rely on port publishing configured on the Gluetun container. Treat Gluetun as the network edge for every attached application. If several containers depend on it, document that dependency clearly so future updates do not accidentally separate an application from the VPN firewall.
Docker port mapping and VPN port forwarding are not the same thing
This distinction is critical. Mapping `8080:8080` on Gluetun makes an application Web UI reachable from the Docker host or LAN on that host port. It does not ask the VPN provider to accept unsolicited internet traffic. Provider-side port forwarding is a separate feature implemented through the VPN service, and only some providers support it.
Gluetun explicitly documents VPN server port forwarding separately from ordinary Docker port mapping. If your application needs an inbound peer port, verify provider support. Surfshark does not offer normal VPN port forwarding, so Gluetun cannot manufacture that feature for a Surfshark tunnel. The application can still make outbound connections normally, but incoming connectivity behavior will differ from a provider that assigns a forwarded port.
Allow only the LAN subnets you actually need
Gluetun's firewall is designed to prevent traffic from escaping the VPN. When an attached application also needs to reach a NAS share, a local API or a Web UI client on the LAN, add the required subnet through the documented firewall settings rather than disabling protection. `FIREWALL_OUTBOUND_SUBNETS` is the important control for allowing selected private destinations.
Be careful with overlapping address space. If your home LAN, Docker network, Tailscale subnet and provider WireGuard range collide, the kernel can send traffic through the wrong route. Use a deliberate IP plan and allow the smallest private subnet necessary. A broad `0.0.0.0/0` exception would defeat the point of the VPN firewall.
Keep Tailscale and Gluetun in separate roles
Tailscale is excellent for private inbound NAS access; Gluetun is excellent for selected outbound provider VPN traffic. They can coexist cleanly when Tailscale runs on the host or its own container and privacy-sensitive applications share Gluetun. There is usually no reason to force Tailscale itself through Gluetun.
This separation solves a common problem: administrators want to reach the NAS remotely even if the commercial VPN is down. If Tailscale depends on the provider tunnel, a provider outage can lock you out. If Tailscale stays independent, you can still administer the NAS and repair the VPN stack. Build optional services so their failures do not control the management plane.
Gluetun on Synology, QNAP and other appliances
On an appliance NAS, the practical question is whether the Docker/container platform exposes the features needed for Gluetun, including the appropriate network and tunnel capabilities. Synology Container Manager and QNAP Container Station can support sophisticated stacks, but exact behavior can vary by model, operating-system version and how the vendor exposes device capabilities. Follow current platform documentation and test on the specific system.
If the appliance interface makes the container network awkward, a router-level policy or separate mini PC can be cleaner than forcing an unsupported host tweak. The goal is a maintainable VPN gateway, not a configuration that depends on hidden package changes after every NAS update. Keep backups of Compose files and environment variables outside the container runtime.
Gluetun on Unraid versus VPN Manager
Unraid has a strong native option: import a provider WireGuard configuration into VPN Manager and assign selected containers to the resulting custom `wgX` network. This avoids running a separate VPN gateway container. It is a good choice when the deployment is permanently tied to Unraid and the provider configuration works well with its native WireGuard stack.
Gluetun is more portable and adds a provider-focused container firewall, DNS controls and a familiar Compose pattern. It is useful when you want the same architecture across hosts or when several applications should share one gateway container. The choice is architectural rather than ideological. Use the tool that creates the fewest hidden dependencies for your server.
Monitoring and health checks
A VPN container should not be treated as “set and forget.” Monitor whether the tunnel is up, whether the public IP matches the provider, and whether DNS remains on the intended path. Use container health checks and dependency conditions carefully so applications do not start before the gateway is ready. After updates, repeat the public-IP and leak tests rather than assuming the previous result still applies.
Restart the VPN deliberately during maintenance and watch what happens to attached applications. They should lose external connectivity while the tunnel is unavailable and recover cleanly after reconnection. A predictable failure mode is one of the main reasons to use a dedicated gateway container in the first place.
NAS hardware considerations
Gluetun itself is not a heavy workload, but the applications around it can be. Torrent clients, ARR applications, databases, Plex and photo services can consume significant RAM, CPU and storage I/O. More memory reduces pressure when many containers run simultaneously, while a capable CPU helps with media processing and encryption under load. Fast network interfaces matter for local transfers, although they do not increase WAN speed.
When buying a NAS for this architecture, prioritize container support, bays, memory expansion and the broader application workload. The live Amazon listing above connects this networking guide with current enclosure options because many readers are building the server and VPN stack at the same time. It should not be interpreted as a requirement to replace a NAS that already runs Docker reliably.
A clean deployment checklist
Create the Gluetun container with provider credentials stored securely, then verify the tunnel before attaching applications. Add one dependent container, map its management port on Gluetun, allow only the necessary LAN subnet and confirm the public IP from inside the application. Stop Gluetun and verify the application loses external connectivity. Restart the stack and confirm recovery.
After that, add additional containers one at a time. Test NAS local services, Plex, Tailscale and backups separately so you know they remain independent of the provider tunnel. Document the provider protocol, local subnet exceptions and published ports. This turns Gluetun from a clever Docker trick into a network component you can actually maintain over the life of the NAS.
Sources and methodology
Cloudzat checks current vendor and platform documentation before publishing networking guidance. VPN clients, NAS operating systems, container images and remote-access behavior can change, so verify the current vendor instructions before modifying a production server.
Research snapshot: August 24, 2026. Recheck current platform, VPN and container documentation before changing a production network.