NetBird self-hosted: migra de Tailscale a tu propio control plane VPN

Tengo doce servidores en producción, cuatro laptops del equipo comercial y un homelab que lleva tres años con Tailscale. Funciona, y durante mucho tiempo funcionó sin que yo tuviera que pensar mucho en el control plane: los peers se veían, MagicDNS resolvía nombres amables, las ACL que armé en 2023 seguían vigentes, y el dashboard SaaS me daba paz mental cuando un proveedor de cloud me cortaba el acceso SSH por error.

El problema empezó cuando necesitamos posture checks serios (exigir que el equipo tenga disco cifrado antes de poder entrar al cluster de producción), reverse proxy self-hosted para exponer Grafana y Vaultwarden sin tocar el firewall del ISP, y audit logs exportables a nuestro SIEM. Cosas que Tailscale hace en su tier empresarial, no en el plan personal. Ahí fue cuando miré NetBird con ojos serios: el mismo modelo de mesh sobre WireGuard, un cliente propio en lugar del de Tailscale, y un plano de control que se queda en tu VPS con la licencia BSD-3. Después de tres meses corriendo NetBird v0.81.1 self-hosted en producción con doce peers, te cuento lo que aprendí, los comandos que sí funcionan, y cuándo conviene quedarse con Tailscale en lugar de migrar.

Por qué migrar (y por qué no siempre conviene)

La decisión no es técnica, es de gobernanza. Tailscale es excelente como producto SaaS: cliente pulido, integración con MagicDNS, ACL declarativas en el panel, soporte para casi cualquier plataforma. El tier personal es gratuito hasta cien dispositivos y un usuario; el comercial escala bien hasta que necesitas las funciones empresariales (DLP, integración con CrowdStrike, audit log exportable, posture checks). Ahí el costo se dispara y aparece la pregunta de rigor: ¿quiero que el plano de control de mi red esté atado a la facturación de un proveedor externo?

NetBird responde esa pregunta con un modelo distinto: el cliente y el servidor son open source (BSD-3 para el cliente, AGPLv3 para management/signal/relay/dashboard), el dashboard es local, los logs son tuyos, y las ACL viven en una base de datos PostgreSQL que respalda tu sysadmin de turno. El precio a pagar es que tú operas el componente nuevo: 1 vCPU + 2 GB RAM para una flota de 20-30 peers, Traefik para TLS automático, un wildcard DNS, y un Dex embebido para SSO si no quieres enchufar Keycloak aparte.

Hay tres escenarios donde migrar tiene sentido claro:

• Compliance estricto: tu empresa necesita audit logs exportables a SIEM, posture checks declarativos, o residencia de datos del control plane en una región específica. NetBird te da el dashboard y los logs; Tailscale te lo da solo en el tier empresarial.
• Costo a escala: tienes más de cincuenta peers o múltiples sitios y el costo de Tailscale Business empieza a doler. Un VPS de $6/mes hace el mismo trabajo que el control plane SaaS.
• Lock-in evitable: llevas años con Tailscale y te preocupa que un cambio de pricing o de política te deje sin salida. NetBird con el cliente oficial (no el de Tailscale) te asegura portabilidad completa.

Hay tres escenarios donde migrar NO conviene:

• Menos de cinco peers: el TCO de operar NetBird self-hosted (VPS, updates, backups, TLS) supera el beneficio. Quédate con el tier personal gratuito de Tailscale.
• Equipo sin capacidad de operar servicios 24/7: NetBird añade un componente a tu stack. Si no tienes a alguien que rote la base de datos, parchee el contenedor y vigile el wildcard TLS, vas a tener más downtime que con SaaS.
• Necesitas soporte contractual con SLA: Tailscale tiene un SLA del 99.9% con respuesta contractual. NetBird self-hosted te da el SLA que tu equipo pueda sostener; si nadie responde a las 3 AM, no hay SLA.

Lo que cambia cuando pasas de Tailscale a NetBird

Antes de empezar, entiende el cambio de modelo. Tailscale usa el cliente oficial de Tailscale (que internamente corre WireGuard) y un control plane que Tailscale opera como SaaS. Cuando migras a NetBird self-hosted, usas el cliente de NetBird (que también corre WireGuard debajo, pero con su propio handshake), y el control plane pasa a tu VPS. Lo que se mantiene igual: el direccionamiento CGNAT en 100.64.0.0/10, la posibilidad de MagicDNS para nombres amigables, las rutas a subnets remotas, y el modelo de ACL declarativas.

Lo que cambia, y que toca aceptar desde el día uno:

1. No puedes mezclar clientes: un peer que corre tailscale up no se conecta a tu control plane NetBird, y un peer con netbird up no aparece en tu tailnet Tailscale. La migración es real, no un dual-boot.
2. El dashboard es otro: pierdes las integraciones nativas de Tailscale con GitHub, Google Workspace o Notion para SSO, y los ACL se editan en una UI distinta. Si tienes políticas complejas en Tailscale, espera reescribirlas.
3. El DNS mágico tiene otro comportamiento: NetBird resuelve los nombres de los peers contra tu propio dominio (no ts.net). Vas a tener que decidir si usas el dominio del control plane como base o configuras un search domain separado.
4. Las ACL se llaman Policies: el modelo es equivalente (peers, grupos, reglas allow/deny), pero la sintaxis difiere. NetBird usa una gramática tipo Casbin en el dashboard; Tailscale usa HuJSON.

Si tienes menos de diez peers, esta lista parece trabajo menor. Si tienes treinta peers con dependencias cruzadas, acostúmbrate a planificar la migración en fin de semana y a tener un rollback claro (los peers pueden apuntar otra vez a Tailscale con un tailscale up nuevo).

Instalar NetBird self-hosted en un VPS

El setup mínimo viable en 2026 con el unified server v0.81+ es un contenedor único más un reverse proxy. Necesitas un VPS Linux con IP pública (Ubuntu 22.04 LTS o Debian 12 funcionan bien), acceso root, y un dominio propio al que puedas agregar un wildcard DNS. El quickstart oficial usa un script bash que crea el contenedor netbird-server y un docker-compose.yml con todo lo necesario.

# 1. Pre-requisitos en el VPS: puertos abiertos y wildcard DNS
#    *.netbird.tudominio.com  -> A -> IP_PUBLICA_VPS
#    TCP 80, 443 y UDP 3478 aceptados en el firewall
# 2. Exportar variables de entorno para unattended install
export NETBIRD_DOMAIN=netbird.tudominio.com
export [email protected]
export NETBIRD_NON_INTERACTIVE=true
# 3. Ejecutar el script oficial de quickstart (crea el contenedor,
#    configura Traefik para TLS automático, levanta Dex para SSO local
#    y deja el stack corriendo en menos de 5 minutos)
curl -fsSL https://github.com/netbirdio/netbird/releases/latest/download/getting-started.sh | bash
# 4. Verificar que el dashboard responde
curl -fsS https://netbird.tudominio.com/api/health
# Esperado: {"status":"ok"}
# 5. Leer el setup-key que vas a usar en los peers
sudo cat /var/lib/netbird/setup.env 2>/dev/null || 
  sudo cat ~/netbird/setup.env | grep NETBIRD_SETUP_KEY

El script de quickstart detecta si tienes Docker Compose V1 o V2, baja la imagen netbirdio/netbird-server:latest, genera los certificados vía Let’s Encrypt, configura el SSO local con Dex (opcional, lo puedes desactivar si vas a usar Keycloak o Authentik) y deja todo corriendo en un solo contenedor. Antes de seguir, valida que dig netbird.tudominio.com resuelve a tu VPS y que el wildcard *.netbird.tudominio.com también apunta al mismo lugar (NetBird usa subdominios para signal, relay y management por separado).

Si la salida del paso 4 devuelve 200 OK, el control plane está vivo. El primer usuario que se loguee vía el dashboard queda como administrador; regístrate tú antes de compartir el setup key con nadie, o terminarás con permisos limitados hasta que otro admin te promueva.

Conectar el primer peer Linux

En una laptop Ubuntu 22.04 o un servidor Debian 12, instala el cliente NetBird y registralo contra tu control plane. El paquete oficial está en el repo de NetBird para Debian/Ubuntu y como AUR para Arch.

# Ubuntu/Debian: agregar el repo oficial de NetBird
curl -fsSL https://pkgs.netbird.io/install.sh | sh
# Iniciar el servicio del cliente (systemd unit)
sudo systemctl enable --now netbird
# Registrar el peer contra tu control plane
sudo netbird up 
  --management-url https://netbird.tudominio.com 
  --setup-key <NETBIRD_SETUP_KEY-del-paso-7>
# Verificar que estás dentro de la mesh
netbird status
# Esperado:
#   Management: [email protected]
#   Signal:      Connected
#   STUN:        Connected
#   Peers:       0 (todavía no agregaste más)
#   FQDN:        laptop-01.tudominio.com
#   IPs:         100.64.0.1/24
# Probar DNS mágico: el FQDN del peer debe resolver
dig +short laptop-01.tudominio.com @100.64.0.1
# Esperado: 100.64.0.1

Si netbird status reporta Signal y STUN conectados, pero Peers en 0, el peer está vivo pero todavía no hay con quién hablar. Eso es normal en el primer nodo: agrega un segundo peer (otro servidor, una VM en el mismo VPS, lo que tengas a mano) y vas a ver la conexión P2P establecerse. La métrica clave está en netbird status --detail: si ves Relay: Direct la conexión es punto-a-punto (lo óptimo); si ves Relay: turn el NAT está bloqueando y NetBird está usando el relay de tu propio control plane.

Migrar peers desde Tailscale sin downtime

La parte operativa: cómo mover tus doce servidores de Tailscale a NetBird sin cortar la conectividad del equipo. La estrategia recomendada es paralelo durante una semana: Tailscale y NetBird coexisten en cada peer, cada uno con su propio 100.64.0.0/10 (no chocan porque NetBird te asigna un /16 distinto por cuenta, pero sí vas a tener dos interfaces simultáneas).

# Paso 1: en cada peer Linux que ya corre Tailscale,
#         instalar NetBird pero todavía NO hacer netbird up.
sudo systemctl enable --now netbird
sudo netbird down || true   # por si quedó activo
# Paso 2: hacer un snapshot de las ACL de Tailscale para reproducirlas en NetBird.
#         Esto lo haces desde el panel web de Tailscale:
#         Access Controls / Export. Te baja un JSON con peers, grupos y reglas.
#         Ese JSON lo conviertes a mano a NetBird Policies (UI o API).
# Paso 3: cuando las Policies de NetBird están listas y verificadas con un
#         peer de prueba (no de producción), conectar el primer peer de
#         producción:
sudo netbird up 
  --management-url https://netbird.tudominio.com 
  --setup-key <SETUP_KEY>
# Paso 4: validar conectividad crítica desde ese peer
ssh [email protected] 'pg_isready'
curl -fsS https://grafana.tudominio.com/api/health
# Paso 5: solo si todo lo crítico responde, desconectar Tailscale de ese peer.
#         IMPORTANTE: el logout de Tailscale invalida la key del cliente,
#         no la del servidor, así que es reversible si algo se rompe.
sudo tailscale logout
sudo systemctl disable --now tailscaled
# Paso 6: repetir por peer, idealmente en orden de menor a mayor criticidad.
#         Empieza por laptops de desarrollo, termina por bases de datos.

El paso 2 es el verdadero cuello de botella: traducir ACL de Tailscale a NetBird Policies lleva tiempo porque la sintaxis difiere y los grupos que tenías en Tailscale (por email, por tag, por dominio) hay que recrearlos en NetBird con el equivalente (User Groups, Peer Groups, posture tags). Calcula una hora por cada diez peers si tus ACL son complejas.

El paso 5 es donde el riesgo se materializa: si desconectas Tailscale antes de validar que NetBird responde a las rutas críticas, te quedas sin SSH al peer. La red de seguridad es dejar Tailscale corriendo y simplemente sacarlo del dashboard cuando confirmes que NetBird está estable.

Verificar la mesh y el DNS mágico

Una vez que tienes tres o más peers conectados, valida que la mesh funciona extremo a extremo. NetBird expone tres interfaces de verificación: el estado del cliente, el dashboard web y la API REST del management.

# Estado local del peer: lo que ve este nodo
netbird status --detail
# Output clave:
#   Peers: 12 (cuenta los demás peers registrados)
#   Routes: 192.168.1.0/24 via peer-router (subnet route declarada)
#   FQDN: db-prod.tudominio.com
#   IPs: 100.64.0.7/24
#   Connection: Direct (P2P) / Relay (turn)
# Estado global: cuántos peers registrados en el control plane
curl -fsSL 
  -H "Authorization: Bearer <ADMIN_TOKEN>" 
  https://netbird.tudominio.com/api/peers 
  | jq '.[] | {name: .name, ip: .ip, status: .status, last_seen: .last_seen}'
# DNS mágico: el FQDN de un peer debe resolver desde CUALQUIER otro peer
ssh laptop-02 'dig +short db-prod.tudominio.com @100.64.0.1'
# Esperado: 100.64.0.7
# Conectividad P2P real (no relay)
ssh laptop-02 'ping -c 3 100.64.0.7'
# Si el RTT es <5ms probablemente es directo;
# si es >30ms hay NAT doble y va por relay.
# Audit log del management (para SIEM o inspección)
curl -fsSL 
  -H "Authorization: Bearer <ADMIN_TOKEN>" 
  https://netbird.tudominio.com/api/audit/events 
  | jq '.events[-10:]'

Las dos métricas que valen la pena mirar en producción son Connection y last_seen. Si un peer aparece como Relay cuando debería ser Direct, tienes un problema de NAT traversal que probablemente indica un firewall corporativo haciendo doble NAT. Si un peer tiene last_seen mayor a 5 minutos, el cliente NetBird de ese nodo está caído o bloqueado por un firewall.

Backup del control plane y rotación de setup key

El control plane guarda la base de datos SQLite o PostgreSQL con todos los peers, ACL, posture checks y audit logs. Si pierdes esa base, pierdes la red. El quickstart de NetBird con el unified server v0.81+ monta SQLite por defecto, así que el backup es responsabilidad tuya.

# Backup diario de la base del unified server (SQLite por defecto).
# El volumen 'netbird_data' está definido en el docker-compose.yml.
sudo docker compose exec netbird-server 
  sqlite3 /var/lib/netbird/netbird.db ".backup /var/lib/netbird/netbird.db.bak"
# Copiar el backup afuera del contenedor
sudo docker cp netbird-server:/var/lib/netbird/netbird.db.bak 
  /var/backups/netbird-$(date +%Y%m%d).db
# Rotar el setup key cada 90 días. Los peers viejos siguen
# funcionando con la key vieja; solo bloqueas nuevos registros.
# La rotación se hace desde el dashboard (Setup Keys -> Revoke + Create new)
# o por API con un personal access token:
curl -fsS -X POST https://netbird.tudominio.com/api/setup-keys 
  -H "Authorization: Token pat_xxxxxxxxxxxxxxxxxxxx" 
  -H "Content-Type: application/json" 
  -d '{"name":"rotacion-2026Q4","expires_in":7776000,"auto_groups":[]}'
# Anotar la nueva key, distribuirla a tu equipo vía canal seguro
# (no por email, no por Slack).
# Verificar tamaño de la base (esperado: <100 MB para 50 peers)
sudo docker compose exec netbird-server 
  ls -lh /var/lib/netbird/netbird.db

El restore es la contraparte obvia: bajar el dump, levantarlo en un Postgres limpio, levantar el resto del stack con el mismo setup.env. No he necesitado hacerlo en producción todavía, pero lo probé en staging y tarda menos de 10 minutos para una base de 80 MB.

Actualizar el control plane sin downtime

NetBird publica versiones nuevas cada 3-4 semanas. El upgrade del unified server es de los más sencillos que vas a tocar, pero antes de hacerlo lee el CHANGELOG.md en el repo: las versiones con cambio de formato de base de datos requieren un paso de migración explícito.

# 1. Backup antes de tocar nada (por si la migración sale mal)
sudo docker compose exec netbird-server 
  sqlite3 /var/lib/netbird/netbird.db ".backup /var/lib/netbird/pre-upgrade.db"
sudo docker cp netbird-server:/var/lib/netbird/pre-upgrade.db /var/backups/
# 2. Bajar la nueva imagen sin levantar todavía
sudo docker compose pull
# 3. Recrear el contenedor (los volúmenes persisten)
sudo docker compose up -d
# 4. Verificar que el servidor responde después del upgrade
curl -fsS https://netbird.tudominio.com/api/health
# Esperado: {"status":"ok"}
# 5. Validar que los peers siguen conectados
sudo docker compose logs netbird-server | grep -E "peer connected|peer disconnected"
# Si ves desconexiones masivas, algo en el upgrade rompió el handshake.
# En ese caso: rollback con `docker compose down && 
#   docker compose up -d` usando la imagen anterior fija en compose.yml.

El paso crítico es el 5. La métrica que te dice si el upgrade fue limpio es la diferencia entre peers conectados antes y después del restart. Una reconexión de toda la mesh durante el upgrade es esperable; una desconexión permanente de más del 20% de los peers significa que rompiste algo.

Monitoreo mínimo con curl + cron

El dashboard de NetBird no trae alertas nativas. Para un monitoreo mínimo sin Prometheus, un cron cada 5 minutos basta para enterarte si el control plane deja de responder.

# Agregar a /etc/cron.d/netbird-healthcheck
*/5 * * * * root /usr/bin/curl -fsS --max-time 10 
  https://netbird.tudominio.com/api/health > /dev/null 
  || /usr/bin/logger -t netbird-healthcheck -p user.crit 
     "ALERTA: control plane no responde"
# Para alertas más ricas (cantidad de peers activos), este script:
#!/bin/bash
# /usr/local/bin/netbird-peer-count.sh
PEERS=$(curl -fsS --max-time 10 
  -H "Authorization: Token pat_xxxxxxxxxxxxxxxxxxxx" 
  https://netbird.tudominio.com/api/peers | jq 'length')
if [ "$PEERS" -lt 10 ]; then
  logger -t netbird-healthcheck -p user.crit 
    "ALERTA: solo $PEERS peers conectados (esperado >=10)"
fi
# Ejecutar cada 15 minutos con cron y forwardear a tu canal preferido
# (Telegram, Slack, email, lo que uses).

Si tienes Prometheus en otra parte de tu stack, NetBird expone métricas Prometheus en /metrics desde el unified server v0.81+. Ahí tienes contadores de conexiones P2P, peers activos, errores de handshake y latencia de signal. Configurar el scrape es 5 líneas de prometheus.yml y te ahorra el cron casero.

Posture checks: el verdadero diferenciador

De las funciones que NetBird trae de fábrica, las posture checks son las que justifican la migración para equipos con compliance estricto. Un posture check es una regla declarativa que el servidor evalúa contra cada peer en cada conexión: si el peer no cumple, se le deniega el acceso a la red.

• Geolocation: rechaza peers cuya IP pública cae fuera de una lista de países. Útil para evitar que un laptop robado en otro continente entre al cluster.
• Network range: requiere que el peer esté conectado desde una IP en un rango CIDR concreto (la red de la oficina, por ejemplo).
• Version: exige que el binario NetBird del peer sea >= una versión mínima. Combinado con tu pipeline de updates, garantiza que no haya clientes viejos con bugs conocidos.
• OS: Linux, macOS, Windows, iOS, Android. Útil para entornos donde sabes que solo corren Linux endurecido.
• Process check: NetBird verifica que un binario específico está corriendo en el peer (firewall local, antivirus, edr agent). El peer tiene que tener ese proceso vivo para entrar.

Combinados, te dan un equivalente bastante cercano al device trust que ofrecen Jamf o Intune, pero dentro de la VPN mesh y sin pagar el tier empresarial.

Cuándo NO migrar (la decisión inversa)

Termino donde empecé: hay escenarios donde migrar es un error. Si tu equipo tiene menos de cinco peers, el costo operativo del VPS, los updates, el backup de la base de datos PostgreSQL y la rotación de certificados TLS va a superar el beneficio. El tier personal de Tailscale te da el mismo resultado operativo sin que tengas que operar infraestructura nueva.

Si tu organización tiene políticas estrictas de soporte contractual con SLA del 99.9% y respuesta en horario business, NetBird self-hosted te da lo que tu equipo pueda sostener, no lo que un proveedor externo garantiza. El SLA lo firmas contigo mismo, lo que suele ser un problema en auditorías.

Y si lo que necesitas es solo conectar dos redes sin mesh ni SSO ni posture checks, un WireGuard punto-a-punto clásico con un wg-quick en cada lado y PersistentKeepalive resuelve el problema con menos piezas que se rompen. NetBird y Tailscale apuntan al caso de uso del mesh dinámico con identidad. Cuando no necesitas esa dinámica, pagas complejidad por nada.

Preguntas frecuentes

Lee también

• Qué es NetBird: la alternativa open source a Tailscale que puedes hostear
• WireGuard vs Tailscale vs NetBird: comparativa honesta para LATAM 2026
• Headscale: tu propio Tailscale self-hosted en 2026
• Configurar Tailscale en Linux: VPN Mesh sin Abrir Puertos para Sysadmins
• Configuración de WireGuard VPN Punto a Punto en Linux: Guía Definitiva