gluetun's real product is the kill switch, not the tunnel

The kill switch is the feature everyone actually wants

Read the feature list in order of how much they matter in practice, and one item dominates. The built-in firewall kill switch is described as allowing traffic only through the VPN, to the VPN server itself, and to allowed devices on the local network. That last exception matters: without it a client that reconnects would also cut off your local printers and NAS. Next comes DNS, and there are three separate claims. DNS over TLS is built in with a service provider of your choice, DNS fine-blocking of malicious and advertising hostnames and addresses updates live every twenty-four hours, and split-horizon DNS is possible by selecting more than one resolver. So this is not a VPN dialer with a firewall bolted on. The tunnel is the reason it exists, and the leak protection is the product.

Three proxies run inside the same container as the tunnel

The container exposes three proxy servers alongside the VPN connection, which is what makes the single-container model work for applications that only speak a proxy protocol. There is a Shadowsocks proxy server, described as a protocol based on SOCKS5 with an encryption layer, tunnelling both TCP and UDP. There is a plain SOCKS5 proxy server, also tunnelling TCP and UDP, with partial credit given to two contributors. And there is an HTTP proxy, which tunnels both HTTP and HTTPS over TCP. The compose example in the readme shows the shape of this: one published port for the HTTP proxy and the same port published twice, once for TCP and once for UDP, for Shadowsocks. You can therefore point a torrent client, a browser or another container at whichever protocol it already speaks, without each of them needing VPN configuration of its own.

OpenVPN works everywhere, Wireguard only for some providers

The provider list has twenty-two names, and the protocol support is not uniform, which is the detail that trips people up. OpenVPN is supported for every provider listed. Wireguard is supported in both kernelspace and userspace flavours for eight named providers. A second group can only use Wireguard through the custom provider configuration, with a link to that page, and custom Wireguard configurations use the same route. One provider is marked as Wireguard only. AmneziaWG is supported only through the custom provider for now. More is listed as in progress with an issue to watch. So when you read that a provider is supported, check whether your intended protocol is in the first group or needs the custom path, because the difference is first-class integration versus a configuration you maintain yourself.

The compose file needs a capability, a device and a named volume

The readme calls its example the laziest one and publishes it in full, which is useful precisely because it shows the three things that are not optional. It adds the network administration capability, maps the tun device from the host, and mounts a volume at a fixed path inside the container. The published ports are annotated inline so you can tell which service is on which, and a comment above the container name explains that it must be uncommented if you want other containers to connect. The published example is:

---
services:
  gluetun:
    image: qmcgaw/gluetun
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    ports:
      - 8888:8888/tcp # HTTP proxy
      - 8388:8388/tcp # Shadowsocks
      - 8388:8388/udp # Shadowsocks
    volumes:
      - /yourpath:/gluetun

The environment block points at the wiki for the variables you will actually need, since credentials and provider selection live there rather than in the example. The image is published twice, on Docker Hub and on a second registry path, which is worth knowing if you mirror images into a private registry. Everything else is documented per provider.

Other containers and LAN devices route through it, and there is a sidecar story

The deployment model is the part that decides whether this container earns its place. Two documentation pages exist for it: one for connecting another container to the running instance, and one for connecting a device on your local network to it. Both matter, and they are different problems, because routing a sibling container through a process is a compose networking question while routing a printer or a television through it is a gateway question. There is also a stated capability to run as a Kubernetes sidecar, credited to a contributor, which is the same idea expressed for an orchestrator. Read together, the design is: one instance holds the connection and the protections, and everything else on the network or in the compose file borrows it. That also means the container is a single point of failure, which is exactly what the kill switch is designed to make safe.

Six CPU architectures, and a build that fetches its own tools

The compatibility list is longer than most projects of this size offer: 64-bit Intel, 32-bit Intel, 64-bit ARM, 32-bit ARM in two variants, and 64-bit Power PC. The image is built on a current Alpine release and the readme states the size, which is the number people quote when they ask why this exists instead of a full VPN client on the host. The Dockerfile shows the build in more detail than the readme does. Build arguments pin the Alpine version for both the runtime and the Go toolchain, the Go version itself, and the versions of three tools fetched from the maintainer's own image registry: xcputranslate, a linter, and a mock generator. The build stage installs git, a C++ compiler, findutils with an inline comment explaining that a particular flag is needed for the mock generation stage, and the packet filtering tool the kill switch depends on.

The module path is the old one, and the project changed owners in May

Two things about identity are worth knowing. The module declaration in the source still names the author's original repository path, even though the code now lives under a different organisation, which is normal for a fork or a move and matters only if you write a replace directive. The readme carries a dated note announcing the move, giving a specific date in May 2026, explaining that it was prompted by paperwork around moving sponsorship to an open source collective, and promising that donated funds will only be used for the project. It also states that the container image names will not change, which matters more than it sounds if you pin images in compose files. The readme opens with a warning that the repository and its wiki are the only official sites and that other sites claiming to be official are scams. The dependency list shows the shape of the code: a long run of the author's own small modules for settings, shutdown, logging, service trees and the server list, plus netfilter and Wireguard control packages.

Editorial conclusion

gluetun fits a homelab or a NAS user who wants every other container's traffic to leave through one VPN connection with a kill switch behind it, and who is willing to read the wiki page for their provider before configuring it. It does not fit someone who only needs a desktop client, or someone whose provider offers Wireguard only through the custom configuration path and expects first-class support for it. Before you deploy it, read the compose example properly rather than copying the shortest version, because it needs elevated capabilities and a tun device and it will silently become useless without them. Then check the provider list for the protocol you want, since OpenVPN is universal and Wireguard is not. The newest release is v3.41.3 from 2026-07-30.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes