Pi-hole y AdGuard Home en Docker para cloud: HTTPS, DoH upstream y acceso remoto seguro

Tengo un homelab modesto: una Raspberry Pi 5 con unos cuantos contenedores Docker, un par de VPS en Hetzner para servicios externos, y la red de mi casa con dispositivos que van desde teléfonos hasta una freidora conectada. Durante mucho tiempo usé Pi-hole instalado directo sobre Debian bare-metal, y me funcionó. El problema empezó cuando quise moverlo a un VPS en la nube para tener DNS filtrado también cuando estoy fuera de casa con la red celular del teléfono. Ese movimiento me obligó a pensar en cosas que en casa no me preocupaban: HTTPS para el panel de admin, DNS-over-HTTPS para no enviar consultas en texto plano, y un canal cifrado para consultar logs desde el teléfono sin abrir el puerto 80/443 al mundo.

Si llegaste aquí porque quieres migrar de un setup bare-metal o local a algo más robusto, este post es para ti. Vamos a desplegar los dos ad-blockers de DNS más usados del ecosistema Linux (Pi-hole y AdGuard Home) en Docker, dentro de un VPS, con HTTPS automático para el panel, DoH para las consultas upstream, y Tailscale para que puedas administrar todo desde donde estés sin abrir puertos riesgosos.

Por qué Docker en la nube cambia el approach

Hasta hace poco la receta canónica era instalar Pi-hole o AdGuard Home directo sobre el sistema operativo del servidor, modificar /etc/dnsmasq.d/, abrir el puerto 53 en ufw y olvidarse. Funciona, y de hecho hay guías excelentes para ese setup. Pero cuando tu servidor de DNS vive en un VPS en la nube, hay tres problemas que ese approach no resuelve bien:

1. El panel admin queda expuesto en HTTP plano. Por defecto AdGuard Home escucha en 0.0.0.0:3000 y Pi-hole en 0.0.0.0:80 + 4711. Si abres esos puertos al mundo, cualquier persona puede ver tu panel desde la IP pública y, peor, intentar ataques de fuerza bruta contra la contraseña.
2. Las consultas upstream salen en texto plano. Por defecto Pi-hole y AdGuard Home preguntan a 1.1.1.1, 8.8.8.8 o 9.9.9.9 por UDP al puerto 53. Tu proveedor de VPS ve cada dominio que tu red visita. Si te importa la privacidad (y debería, estás montando un ad-blocker precisamente por eso), quieres DNS-over-HTTPS o DNS-over-TLS hacia el upstream.
3. Migrar entre Pi-hole y AdGuard Home duele. Las configuraciones viven en archivos del sistema, los logs se mezclan con syslog, y los backups son manuales. Con Docker, todo está en docker-compose.yml + un volumen, y mover de un contenedor a otro es copiar un directorio.

Docker resuelve estos tres problemas: el panel queda detrás de un reverse proxy con HTTPS válido (Caddy o Nginx + Let’s Encrypt), las consultas upstream salen cifradas (configurando DoH/DoT en Pi-hole o AdGuard), y la configuración vive en un volumen que puedes versionar y migrar.

Elegir VPS y dominio

Cualquier proveedor Linux moderno sirve. Para este post uso Hetzner Cloud con un CX22 (4 vCPU, 8 GB RAM, ~4€/mes) corriendo Ubuntu 24.04, porque tiene buen precio en Europa y Latam y soporta IPv6 sin fricción. DigitalOcean, Vultr, OVH y AWS Lightsail también funcionan con los mismos pasos; las direcciones de ip de los rangos más comunes cambian por proveedor, pero la lógica es la misma.

Sobre el dominio: estrictamente opcional. Si solo vas a administrar el panel desde tu casa con Tailscale, puedes acceder por http://100.x.x.x:8080 y ya. Pero si quieres HTTPS válido sin warnings del navegador, necesitas un dominio. Yo uso pi.example.com como subdominio dedicado al panel; un dominio de 8€/año en Namecheap o Porkbun te basta.

Tres cosas que importan al elegir el VPS:

• IPv4 pública fija: algunos proveedores cambian la IP en cada reboot, lo cual rompe el setup si tu router aprende la IP vía DNS dinámico.
• Acceso root sin fricción: SSH con clave, sin panel del proveedor bloqueando puertos.
• Sin restricciones en el puerto 53 UDP/TCP: algunos proveedores (especialmente en planes shared) bloquean el puerto 53 outbound para evitar abuso. Verifica antes.

Preparar el VPS

Antes de tocar Docker, deja la máquina lista. Estos tres pasos son los mismos para Pi-hole o AdGuard Home; los diferencio más adelante cuando llegue la hora de desplegar.

Actualizar el sistema y crear usuario no-root

Primero, actualizo paquetes y creo un usuario dedicado para no trabajar como root. La primera línea del bloque actualiza índices y paquetes upgrade; la tercera agrega el usuario al grupo docker para que pueda correr comandos sin sudo; la cuarta instala sudo si la distribución minimal no lo incluye.

apt update && apt upgrade -y
adduser --disabled-password --gecos "" sysadmin
usermod -aG docker,sudo sysadmin
apt install -y sudo ufw fail2ban

Si tu distribución no trae sudo preinstalado, instala sudo aparte y agrégalo al usuario. fail2ban te protege de los bots que van a probar SSH contra tu IP apenas la vean.

Abrir solo los puertos que necesitas

Por defecto, el firewall de Ubuntu (ufw) bloquea todo entrante. Necesitas abrir SSH (22/tcp), DNS (53/udp + 53/tcp) si quieres responder consultas desde fuera del VPS, y el panel admin solo para Tailscale. NO abras el puerto 80/443 al mundo si tu panel va a vivir detrás de Tailscale.

ufw allow 22/tcp
ufw allow 53/udp
ufw allow 53/tcp
ufw default deny incoming
ufw default allow outgoing
ufw enable

El puerto 53 queda expuesto a internet porque tu red local (que está detrás del router de tu casa) va a salir al VPS por la IP pública del VPS, no por una IP de estado de Tailscale. El puerto 80/443 NO se abre porque el panel admin se sirve solo dentro de la red mesh de Tailscale.

Instalar Docker Engine y compose

Docker tiene repositorio propio en Debian/Ubuntu, así que conviene instalarlo desde ahí para recibir actualizaciones de seguridad. El primer bloque agrega el repo oficial; el segundo instala los componentes; el tercero verifica que el daemon responde (el comando “docker run hello-world“ baja y ejecuta un contenedor de prueba).

install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | gpg --dearmor -o /etc/apt/keyrings/docker.gpg
chmod a+r /etc/apt/keyrings/docker.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" | tee /etc/apt/sources.list.d/docker.list > /dev/null
apt update
apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Si tu distribución es Debian en lugar de Ubuntu, cambia ubuntu por debian en la URL del repo y usa el codename de Debian (bookworm, trixie). El resto del comando sigue funcionando porque Docker mantiene paquetes idénticos para ambas.

Desplegar Pi-hole en Docker

Pi-hole es el veterano. La imagen oficial pihole/pihole lleva años en Docker Hub, soporta ARM y AMD64, y consume muy poca RAM (idle con 80-120 MB). El docker-compose abajo monta tres servicios en una serie: el contenedor principal con DNS 53, el servidor web en 8080, y los volúmenes para configuración.

mkdir -p /opt/pihole && cd /opt/pihole

Crea el directorio del proyecto. Convencionalmente uso /opt/pihole para Pi-hole y /opt/adguard para AdGuard, así puedo tener ambos en el mismo VPS corriendo en paralelo si quiero comparar.

Ahora el docker-compose.yml. La imagen oficial acepta variables de entorno para password, upstream DNS y timezone; el bloque ports mapea los puertos del contenedor al host (53 DNS, 80 web, 4711 API); cap_add: NET_ADMIN le da permisos para modificar la red del contenedor.

cat > docker-compose.yml <<EOF
services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    restart: unless-stopped
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "8080:80/tcp"
      - "4711:4711/tcp"
    environment:
      TZ: 'Europe/Zurich'
      WEBPASSWORD: 'tu-password-fuerte'
      DNS1: '9.9.9.9'
      DNS2: '149.112.112.112'
      FTLCONF_webserver_api_password: 'misma-password-api'
      FTLCONF_dns_upstreams: '127.0.0.1#5053'
    volumes:
      - './etc-pihole:/etc/pihole'
      - './etc-dnsmasq:/etc/dnsmasq.d'
    cap_add:
      - NET_ADMIN
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"
EOF

El volumen ./etc-pihole persiste la base de datos SQLite con blocklists y whitelist; ./etc-dnsmasq persiste configs custom de dnsmasq si necesitas agregar dominios locales. El DNS1: '9.9.9.9' es Quad9 (soporta DoH), pero por ahora sale en plano al puerto 53; más adelante configuro DoH a través del upstream.

Levanta el contenedor y verifica que arrancó limpio.

docker compose up -d
docker logs pihole 2>&1 | tail -20

El up -d arranca en segundo plano. Si los logs terminan con Pi-hole blocking is enabled y no hay stack traces, todo va bien. Si ves port 53 is already in use, algún otro proceso (a veces systemd-resolved en Ubuntu) está usando el puerto; lo deshabilito más abajo.

Detalle que pisa a mucha gente: Ubuntu Server 22.04+ viene con systemd-resolved activo, que escucha en 127.0.0.53:53 y bloquea a Pi-hole. Antes de levantar el contenedor, deshabilita el servicio local.

systemctl disable --now systemd-resolved
rm /etc/resolv.conf
echo "nameserver 9.9.9.9" > /etc/resolv.conf

Si no haces esto, Docker no puede bindear el 53 al host porque ya hay algo escuchando. El primer comando apaga el resolver local; el segundo borra el symlink que apuntaba al stub de systemd; el tercero pone un resolv.conf plano con un upstream válido.

Desplegar AdGuard Home en Docker

AdGuard Home es la alternativa más moderna. La imagen oficial adguard/adguardhome trae UI web más pulida, soporte nativo de DoH/DoT/QUIC sin proxy externo, y un lenguaje de logs pensado en mayor confianza. Si vienes del mundo Pi-hole, lo más visible es la separación clara entre “configuraciones de filtrado” y “configuraciones de DNS”, y la API REST documentada para scripting.

Mismo procedimiento: directorio dedicado, compose file, levantar.

mkdir -p /opt/adguard && cd /opt/adguard
cat > docker-compose.yml <<EOF
services:
  adguard:
    container_name: adguard
    image: adguard/adguardhome:latest
    restart: unless-stopped
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "3000:3000/tcp"
      - "443:443/tcp"
      - "853:853/tcp"
      - "784:784/udp"
      - "8853:8853/udp"
    volumes:
      - './work:/opt/adguardhome/work'
      - './conf:/opt/adguardhome/conf'
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"
EOF

AdGuard Home expone más puertos que Pi-hole porque trae soporte nativo para DoT (853), DoQ (8853) y HTTPS para el panel (443). El volumen ./work persiste la base de datos y logs; ./conf persiste el AdGuardHome.yaml de configuración. No levantes Pi-hole y AdGuard al mismo tiempo en el mismo VPS: ambos pelean por el puerto 53. Si quieres comparar, levanta uno, apaga el otro con docker compose down.

Levanta y entra al setup inicial.

docker compose up -d
sleep 5
curl -s http://127.0.0.1:3000/ | head -20

El primer comando arranca el contenedor. El sleep 5 da tiempo a que el servicio web termine de inicializar (AdGuard Home tarda unos segundos en su primer arranque). El curl verifica que el servidor responde: si ves HTML del asistente de setup inicial, todo va bien.

Para configurar el panel desde el navegador, abre http://IP-DEL-VPS:3000/. El asistente te guía por los puertos de escucha, los upstream DNS y la contraseña. Una vez terminado, el panel queda en http://IP-DEL-VPS:3000/ (todavía en HTTP plano, sin TLS).

HTTPS para el panel admin con Caddy

Tanto Pi-hole como AdGuard Home escuchan HTTP plano por defecto. Si quieres administrar el panel desde fuera de Tailscale (por ejemplo, desde la red de un café), necesitas HTTPS válido. La opción más limpia hoy es Caddy, porque pide y renueva los certificados de Let’s Encrypt automáticamente sin tocar cron ni scripts.

El primer paso es apuntar tu subdominio al VPS. Crea un registro A en tu DNS para pi.example.com apuntando a la IP del VPS. Una vez que el DNS propaga (5-15 minutos), verifica.

dig +short pi.example.com

Si el comando devuelve la IP del VPS, el DNS propaga. Si devuelve vacío o la IP vieja, espera unos minutos y vuelve a probar.

Caddy corre como contenedor al lado de Pi-hole/AdGuard. La gracia es que Caddy es a la vez reverse proxy y servidor HTTPS automático. El compose abajo asume que AdGuard Home está en localhost:3000; para Pi-hole cambia el upstream a pihole:80 (nombre del servicio de docker-compose).

mkdir -p /opt/caddy && cd /opt/caddy
cat > docker-compose.yml <<EOF
services:
  caddy:
    container_name: caddy
    image: caddy:2
    restart: unless-stopped
    ports:
      - "80:80/tcp"
      - "443:443/tcp"
    volumes:
      - './Caddyfile:/etc/caddy/Caddyfile'
      - 'caddy_data:/data'
      - 'caddy_config:/config'
volumes:
  caddy_data:
  caddy_config:
EOF

El volumen caddy_data persiste los certificados y la ACME account; caddy_config persiste la config cacheada de Caddy. Sin estos volúmenes, cada restart pierde los certificados y vuelve a pedirlos (lo cual puede rate-limited con tres años).

Ahora el Caddyfile. La directiva reverse_proxy redirige el tráfico al panel interno; el resto Caddy lo resuelve automáticamente: pide certificado, configura TLS 1.3, redirige HTTP a HTTPS.

cat > Caddyfile <<EOF
pi.example.com {
    reverse_proxy localhost:3000
}
EOF

Si tu panel es Pi-hole en lugar de AdGuard, cambia localhost:3000 por localhost:8080. El hostname es 73.x, lo cual indica que tu panel habla HTTP en ese puerto interno.

Levanta Caddy y verifica.

docker compose up -d
sleep 30
curl -sI https://pi.example.com/ | head -3

El sleep 30 da tiempo a Caddy para negociar el certificado con la ACME de Let’s Encrypt (suele tardar 10-20 segundos). El curl -sI verifica que el panel responde con TLS válido: si ves HTTP/2 200 y server: Caddy, todo va bien. Si ves error de certificado, espera 1-2 minutos y vuelve a probar.

DNS-over-HTTPS upstream cifrado

Por defecto, Pi-hole y AdGuard Home preguntan a los upstream por el puerto 53 en texto plano. Tu proveedor de VPS ve cada dominio que visita tu red, igual que un ISP clásico. Para cerrar eso, configura upstream DoH.

En Pi-hole, ve al panel web → Settings → DNS. Desmarca los upstream por defecto y agrega dos URLs DoH:

• https://dns.quad9.net/dns-query (Quad9, con filtrado de malware)
• https://cloudflare-dns.com/dns-query (Cloudflare, sin filtrado)

Guarda y reinicia el resolver DNS desde el panel (Tools → Restart DNS). Las consultas de tu red ahora salen cifradas al upstream. Tu proveedor de VPS solo ve conexiones TLS a esos dos dominios, no los nombres que preguntas.

En AdGuard Home, ve a Settings → DNS settings → Upstream DNS servers. Agrega las mismas dos URLs DoH en el mismo formato. AdGuard Home trae un test de upstream built-in: presiona el botón “Test upstreams” y te dice si resuelve bien antes de guardar.

Para verificar que DoH está activo, abre una terminal en el VPS y captura tráfico.

apt install -y tcpdump
tcpdump -i any -A 'port 443 and host dns.quad9.net' | head -20

Si DoH está activo, ves TLS cifrado (no nombres de dominio legibles). Si DoH estuviera mal configurado, verías las consultas al puerto 53 plano. Cualquier sysadmin con dos al día puede capturar y leer, así que DoH es la línea de defensa mínima.

Acceso remoto seguro con Tailscale

Tailscale es una VPN mesh basada en WireGuard que no requiere abrir puertos ni configurar NAT. Instalas el daemon en el VPS, generas una auth key desde tu panel de Tailscale, y desde tu laptop/celular te conectas a la IP 100.x.x del VPS sin tocar el firewall.

En el VPS:

curl -fsSL https://tailscale.com/install.sh | sh
tailscale up --authkey=tskey-auth-xxxxxxxxxxxxxxxx

El primer comando instala el daemon de Tailscale. El segundo lo levanta con una auth key reusable; genera una en tu panel de Tailscale. Sin auth key, Tailscale te obliga a hacer login interactivo vía URL, lo cual está bien para probar pero no escala.

En tu laptop y tu teléfono, instala el cliente de Tailscale y entra con tu cuenta. Verás el VPS aparecer con una IP 100.x.y.z. Desde la laptop, abre http://100.x.y.z:8080 (Pi-hole) o http://100.x.y.z:3000 (AdGuard) y entras al panel sin abrir puertos al mundo.

Una ventaja interesante es que puedes cerrar el puerto 80/443 del VPS al mundo exterior y servir el panel solo dentro de la mesh. Para eso, en ufw cambia el allow de 80/443 a solo permitir IPs de Tailscale (100.64.0.0/10):

ufw delete allow 80/tcp
ufw delete allow 443/tcp
ufw allow from 100.64.0.0/10 to any port 80,443 proto tcp

El primer par borra las reglas globales. El tercero las reemplaza con una regla que solo permite acceso desde la red de Tailscale. Cualquier IP fuera de Tailscale recibe conexión rechazada. Si quieres HTTPS válido con Caddy para invitados que no tengan Tailscale, mantén 80/443 abiertos; si solo tú usas el panel, ciérralo.

Blocklists, observabilidad y mantenimiento

El valor real de un ad-blocker de DNS está en las listas que carga. Las listas default de Pi-hole y AdGuard Home filtran alrededor de 100k dominios, pero la mayoría de los anuncios en LATAM están en listas adicionales. Las tres listas que más impacto tienen en mi setup:

• Steven Black: https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts — base sólida que combina varias listas.
• AdGuard DNS filter: https://adguardteam.github.io/AdGuardSDNSFilter/Filters/filter.txt — la lista oficial de AdGuard, incluye trackers.
• EasyList: https://easylist.to/easylist/easylist.txt — clásica para anuncios web.

En Pi-hole, →a Group Management → Adlists, pega las URLs. En AdGuard Home, →a Filters → DNS blocklists → Add blocklist. Después de guardar, →a Tools → Update (Pi-hole) o Filters → Update now (AdGuard Home).

Para observabilidad, ambos vienen con métricas built-in via la API. Un panel de Grafana con Prometheus scrapeando /admin/api.php?summary (Pi-hole) o /control/stats (AdGuard Home) te da queries por minuto, hardware y desde hosts. El setup exacto de Prometheus+Grafana lo cubro en otro post; para empezar, los dashboards built-in de cada uno son suficientes.

El mantenimiento semanal es de 5 minutos: actualizar el sistema (apt upgrade), actualizar las imágenes de Docker (docker compose pull && docker compose up -d) y verificar que las blocklists siguen resolviendo.

Backup y migración entre Pi-hole y AdGuard

La gran ventaja de correr en Docker es que migrar entre los dos es copiar un directorio. Para migrar de Pi-hole a AdGuard Home, lo más limpio es empezar con AdGuard en blanco y exportar la configuración de Pi-hole.

Desde Pi-hole, exporta la configuración via Settings → Teleporter → Backup. Te baja un archivo ZIP con listas, whitelist, blacklist y configuración de DHCP. En AdGuard Home, →a Settings → Import y sube ese ZIP. AdGuard Home convierte las listas de Pi-hole al formato nativo; la blacklist/whitelist se aplica 1:1.

El backup del volumen completo es trivial:

tar czf pihole-backup-$(date +%F).tar.gz -C /opt/pihole .
scp pihole-backup-*.tar.gz usuario@servidor-nuevo:/opt/

El primer comando comprime todo el directorio del proyecto. El segundo lo envía a otro server. Para restaurar, desempaqueta y docker compose up -d. En menos de tres minutos tienes el setup completo en otro VPS.

Si en cambio quieres comparar los dos durante una semana para decidir cuál se queda, levanta Pi-hole y Apóyalo en paralelo en el mismo VPS pero con puertos distintos: cambia el mapeo de puertos del docker-compose de Pi-hole de "53:53" a "5353:53", levanta, y puedes probar ambos cambiando el DNS de tu cliente entre la IP del VPS:puerto 53 y la IP:puerto 5353. No es elegante, pero sirve para A/B testing real antes de comprometerte.

Qué sigue

Con este setup tienes DNS cifrado upstream, panel admin protegido con HTTPS válido, acceso remoto sin abrir puertos y backups que caben en un tarball. Lo próximo que vale la pena mirar es agregar DoH al cliente (en tu laptop y teléfono, no en el server) para cerrar el último tramo: las consultas de tu dispositivo al VPS también cifradas, no solo UPSTREAM cifrado. Firefox y Chrome soportan DoH nativo; en Android, Private DNS en settings apunta a https://pi.example.com/dns-query si quieres cifrado end-to-end.

Preguntas frecuentes

Lee también

• DNS soberano en Linux: Pi-hole o AdGuard Home con Unbound como resolver recursivo
• Configurar Tailscale en Linux: VPN Mesh sin Abrir Puertos para Sysadmins
• Cómo configurar Caddy como reverse proxy en Linux 2026: auto-HTTPS incluido
• dnsmasq: DNS local + DHCP en tu homelab Linux 2026