WireGuard en Docker (2026): la forma limpia de autoalojarlo con docker-compose

Aviso de afiliación — Esta guía enlaza a Contabo, el VPS en el que corre nuestro propio WireGuard autoalojado. Si contratas a través de nuestro enlace, ganamos una comisión sin coste extra para ti. Solo documentamos lo que de verdad ejecutamos.

Ejecutar WireGuard en Docker te da lo que hace que valgan la pena los contenedores: un servidor que levantas, derribas, versionas y trasladas a otro host en minutos, sin un solo paquete instalado en la máquina en sí. La pega: un contenedor VPN no es un contenedor normal — toca la pila de red del kernel, así que unos pocos flags son innegociables. Bien puestos, un WireGuard en contenedor es tan rápido como uno bare-metal. Mal puestos, el túnel conecta pero no enruta nada, en silencio.

Esta es la forma limpia, con forma de producción.

Primero, el error clásico sobre «WireGuard en Docker»

WireGuard es un módulo del kernel. Cuando «ejecutas WireGuard en Docker», el cifrado y el enrutamiento siguen ocurriendo en el kernel Linux del host — el contenedor solo lleva las herramientas de userspace (wg, wg-quick) y tu configuración. Por eso no hay penalización de rendimiento: la ruta de datos nunca entra en el contenedor.

También explica los requisitos. Para crear y gestionar una interfaz de red desde un contenedor, este necesita una capability de red elevada (NET_ADMIN), y el host debe poder reenviar paquetes (net.ipv4.ip_forward=1). No son opciones de endurecimiento — sin ellas, el contenedor se niega a arrancar o levanta sin enrutar nada.

Elige tu imagen: linuxserver/wireguard vs wg-easy

Dos imágenes cubren casi todos los casos:

• linuxserver/wireguard — un servidor limpio gobernado por configuración. Defines los peers mediante variables de entorno o editando archivos en un directorio /config montado. Genera configs de cliente y códigos QR en el primer arranque. Ideal para infrastructure-as-code, muchos peers, o para versionar tu setup en un repo privado.
• wg-easy — WireGuard más un panel web. Crea y revoca peers desde el navegador, escanea códigos QR para móviles, observa el tráfico por cliente en vivo. Ideal para unos pocos dispositivos y alta rápida sin tocar el CLI.

Ambas son maduras y muy usadas. La decisión es panel-vs-archivos, no de calidad.

El archivo docker-compose (wg-easy)

services:
  wg-easy:
    image: ghcr.io/wg-easy/wg-easy:latest
    container_name: wg-easy
    environment:
      - WG_HOST=vpn.example.com        # dominio o IP pública de tu VPS
      - PASSWORD_HASH=<hash-bcrypt>     # login de la interfaz web
      - WG_DEFAULT_DNS=1.1.1.1
    volumes:
      - ./config:/etc/wireguard         # persistencia — mantenlo en el host
    ports:
      - "51820:51820/udp"               # datos WireGuard
      - "51821:51821/tcp"               # interfaz web (firewall a tu IP)
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    sysctls:
      - net.ipv4.ip_forward=1
      - net.ipv4.conf.all.src_valid_mark=1
    restart: unless-stopped

Tres líneas hacen el trabajo pesado y son los puntos de fallo habituales:

• cap_add: NET_ADMIN permite al contenedor gestionar la interfaz wg0. Sin ella, el contenedor no puede levantar el túnel.
• sysctls: net.ipv4.ip_forward=1 convierte la máquina en router. Sin ello, el túnel conecta pero ningún tráfico lo cruza — la causa nº 1 del «dice conectado pero nada funciona».
• volumes: ./config persiste claves y peers en el host para que un recreate no borre a todos los clientes.

Expón el puerto UDP de datos públicamente; pon firewall al puerto TCP de la interfaz web limitándolo a tu propia IP — nunca dejes el 51821 abierto a internet.

La checklist del host (hazla antes de culpar al contenedor)

Un contenedor puede ser perfecto y no enrutar nada por la capa de debajo:

1. Firewall cloud: abre 51820/udp en el security group de tu proveedor, no solo en el host. Es el fallo silencioso nº 1 en un VPS.
2. Módulo del kernel del host: la mayoría de distros modernas traen el módulo WireGuard (Linux 5.6+). Si modprobe wireguard falla en el host, instala las cabeceras del kernel — el contenedor no puede cargar un módulo que el host no tiene.
3. DNS de los clientes: ajusta WG_DEFAULT_DNS para que los clientes no filtren sus consultas a su antiguo resolutor. Combínalo con nuestra guía anti-fugas DNS de WireGuard.

Cuándo el contenedor es la opción correcta — y cuándo no

Usa Docker cuando corres otros servicios en la misma máquina y quieres WireGuard aislado y reproducible, cuando quieres el panel de wg-easy, o cuando redespliegas a menudo entre hosts. Todo el setup se vuelve un archivo compose versionable y trasladable.

Evita Docker cuando el VPS solo hace WireGuard. Un apt install wireguard bare-metal más un archivo de configuración es más simple, tiene una pieza móvil menos, y se scripta trivialmente — mira nuestras plantillas de configuración WireGuard y el tutorial completo Contabo + WireGuard. Para una máquina VPN de un solo propósito, el contenedor añade empaquetado que no necesitas.

El VPS debajo

En contenedor o no, WireGuard necesita un host con IP pública y un enlace decente. Un VPS pequeño basta de sobra — WireGuard es lo bastante ligero para que una instancia de 4–6 €/mes sature su puerto de red mucho antes de que el CPU se inmute. Nosotros corremos el nuestro en Contabo por la relación precio/ancho de banda:

Consigue un VPS Contabo para tu contenedor WireGuard →

Para el desglose completo de precio/rendimiento entre proveedores, mira el VPS más barato para un VPN WireGuard.

La limitación, con honestidad

Docker hace WireGuard portable, no más seguro. El contenedor comparte el kernel del host, corre con NET_ADMIN, y solo está tan blindado como el host. No aísla WireGuard de la máquina — quien tenga root en el host posee el túnel. Trata el contenedor como comodidad de despliegue, endurece el host como si WireGuard estuviera instalado directamente en él, y mantén el puerto de la interfaz web fuera de internet. Hazlo, y WireGuard en contenedor es el setup autoalojado más limpio que hay.