VPS seguro con Hetzner y Tailscale: cerrá el puerto 22

Actualizado el 23/07/2026: El setup dejó de ser solo un truco de hardening y se volvió una categoría: ahora la receta viral es dejar Claude Code en VPS corriendo 24/7 dentro de tmux, con Tailscale como única puerta de entrada y acceso desde el celular. Sumamos requisitos de hardware reales, costos totales del stack y el caso de Pieter Levels, que desarrolla así desde hace un año.

En pocas palabras: El setup cierra el puerto 22 al mundo y deja SSH solo por la red privada de Tailscale (IP 100.64.0.0/10) sobre un VPS Hetzner con Ubuntu 24.04 LTS, más Claude Code corriendo en el servidor para administrarlo sin intervención manual.

Cerrar el puerto 22 al mundo y dejar el acceso SSH solo por una red privada de Tailscale es hoy la forma más práctica de configurar un VPS seguro en Hetzner con Tailscale, sin depender de una VPN corporativa. El servidor queda sin puertos de administración expuestos a internet, y vos entrás por una IP privada del rango 100.x.x.x que solo existe dentro de tu red.

Tailscale es una VPN mesh peer-to-peer construida sobre el protocolo WireGuard, desarrollada por la empresa del mismo nombre, que conecta dispositivos entre sí mediante una red privada superpuesta (overlay). Cada máquina que se une recibe una IP fija del rango 100.64.0.0/10 (CGNAT), y la autenticación se hace contra un proveedor de identidad externo (Google, GitHub, Microsoft) en vez de con claves compartidas. Hetzner Cloud es el proveedor alemán de VPS donde corre el servidor de este tutorial.

¿Por qué es peligroso exponer SSH públicamente en un VPS?

Porque el puerto 22 abierto a internet recibe tráfico automatizado desde el minuto cero. No hace falta que tu servidor sea importante ni que alguien sepa que existe: hay botnets escaneando rangos enteros de IPs de proveedores cloud de forma permanente, y un VPS recién creado empieza a recibir intentos de login en cuestión de horas.

Levantás el servidor, lo dejás andando un fin de semana, volvés el lunes, mirás /var/log/auth.log y te encontrás con miles de líneas de Failed password for root desde IPs de medio mundo, todas probando usuarios genéricos como admin, ubuntu, test, oracle o postgres.

Con autenticación por clave pública y root login deshabilitado, ese ruido no es una brecha. Pero sigue siendo superficie de ataque: cada CVE que aparece en OpenSSH te obliga a parchear con urgencia, y consume CPU y logs. Si el puerto no está abierto, el problema no existe.

Ojo con esto: cambiar el puerto de 22 a 2222 no es seguridad. Es reducción de ruido. Cualquier escaneo con nmap encuentra el servicio igual en diez segundos.

¿Qué es Claude Code en VPS y para qué sirve tenerlo en un servidor?

Claude Code en VPS es la herramienta CLI de Anthropic instalada en un servidor remoto en vez de en tu notebook. Corre en la terminal del VPS, lee y edita archivos del proyecto, ejecuta comandos con tu autorización y sigue trabajando aunque cierres la tapa de la máquina. La diferencia con la instalación local es la persistencia: el agente vive en el servidor, no en tu escritorio.

Eso cambia el flujo de trabajo más de lo que parece. En local, si arrancás una tarea larga y se te apaga la notebook o se corta el WiFi, la sesión muere. En el VPS la sesión queda viva dentro de tmux, y vos te conectás y desconectás cuando querés. Salís de casa, abrís el cliente SSH del celular y ahí sigue el agente, en el mismo punto donde lo dejaste.

• Desarrollo remoto real: el código, las dependencias y el entorno viven en el servidor. No importa desde qué máquina te conectes, siempre es el mismo entorno con las mismas versiones.
• Tareas largas sin niñera: una migración, un refactor grande o un build pesado siguen corriendo con la terminal cerrada. Volvés más tarde y leés el resultado.
• Automatización continua: el agente puede quedar disponible para revisar logs, aplicar parches o responder a un webhook sin que vos estés presente.
• Un solo entorno para el equipo: si trabajan varias personas sobre el mismo servidor, todos ven el mismo estado del proyecto en lugar de “en mi máquina anda”.

La contra es igual de concreta: un agente con permisos en un servidor que importa es un riesgo que no existía cuando todo corría en tu máquina. Y no es un riesgo teórico. Es el mismo cálculo que hacés antes de darle sudo a alguien del equipo.

¿Qué hardware necesita un VPS para correr Claude Code?

Con 2 vCPU y 2 GB de RAM alcanza para arrancar, porque el modelo no corre en tu servidor: la inferencia pasa en la infraestructura de Anthropic y el VPS solo ejecuta el cliente CLI en Node.js. Lo que consume recursos no es el agente sino lo que el agente hace: compilar, correr tests, levantar contenedores o indexar un repo grande. Sobre eso hablamos en automatizar deployments en tu VPS.

Ese es el malentendido más común. La gente busca un VPS con GPU pensando que va a hostear un modelo, y no es el caso. Necesitás CPU y RAM para el toolchain, no para la IA.

El disco engaña. Un repo de 500 MB con node_modules, imágenes de Docker y caches de build se come 20 GB sin que te des cuenta. Y cuando el disco se llena, lo primero que falla no es el agente: fallan los logs y el sistema empieza a comportarse raro.

• Swap sí, aunque tengas RAM: 2 GB de swap en el disco evitan que el OOM killer te mate un build a mitad de camino. Es la diferencia entre un build lento y un build muerto.
• Node.js es el requisito real: el cliente CLI corre sobre Node, así que la versión del runtime importa más que la distribución que elijas.
• Ancho de banda no es problema: el tráfico del agente son requests HTTP a la API, no transferencia pesada. Cualquier plan de VPS lo cubre de sobra.
• Latencia al datacenter, sí: si trabajás interactivo por SSH desde Latinoamérica contra Europa, los 200 ms se sienten al tipear. Para tareas desatendidas da igual.

Sobre el costo total del stack: los VPS de entrada en proveedores europeos rondan los 4-7 dólares mensuales por 2 vCPU, y la suscripción Claude Pro está en USD 20 por mes. El total queda en el orden de USD 25-30 mensuales, que es donde se ubica la cifra que circula en las guías de este setup. Si tu público está en la región, un servidor local como el de donweb.com te ahorra la latencia transatlántica y la receta funciona igual.

¿Qué es Tailscale y cómo crea una red privada segura?

Tailscale arma una red mesh donde cada dispositivo se conecta directo con los demás usando túneles cifrados WireGuard. No hay un servidor central por donde pase el tráfico: los servidores de coordinación de Tailscale solo distribuyen claves públicas y ayudan a atravesar NAT. Una vez establecida la conexión, los paquetes van de tu notebook al VPS sin intermediarios, cifrados punta a punta. Podés complementar esto automatizando despliegues con GitHub Actions.

La diferencia con una VPN comercial tradicional es de topología. Como explican en la guía de configuración de RedesZone, en una VPN clásica todos los clientes se conectan a un concentrador y desde ahí salen: si el concentrador está en Frankfurt y vos estás en Buenos Aires hablando con un servidor en São Paulo, tu tráfico da la vuelta al mundo. Con la topología mesh, cada par negocia el camino más corto.

El flujo de autenticación es lo que la hace usable. Corrés tailscale up, la terminal te escupe una URL, la abrís en el navegador, te logueás con tu cuenta de Google o GitHub, y el dispositivo queda autorizado en tu tailnet. Cero archivos de configuración, cero certificados que copiar a mano, cero ovpn perdidos en la carpeta de descargas.

¿Qué son las IPs 100.x.x.x que asigna Tailscale?

Son direcciones del bloque 100.64.0.0/10, reservado por la IANA para CGNAT (Carrier-Grade NAT) en el RFC 6598. Tailscale las usa porque no son ruteables en la internet pública ni chocan con los rangos privados típicos de redes hogareñas o corporativas (192.168.x.x, 10.x.x.x). Cada máquina de tu tailnet recibe una IP fija de ese bloque que no cambia aunque el dispositivo cambie de red física.

¿Tailscale, OpenVPN o WireGuard puro: cuál conviene?

Para un VPS de uso personal o de un equipo chico, Tailscale gana por costo de operación: la autenticación va contra tu identidad existente y no hay que administrar claves. WireGuard puro es la misma criptografía pero con toda la gestión de peers y claves a tu cargo. OpenVPN es más viejo, más lento y más pesado de configurar.

El “costo” de Tailscale es la dependencia del plano de control. Si sus servidores de coordinación se caen, las conexiones ya establecidas siguen andando (WireGuard es stateless), pero un dispositivo nuevo no se puede sumar. Si eso te preocupa, Headscale es la implementación abierta del plano de control que podés hostear vos mismo.

¿Cómo crear un VPS en Hetzner con Ubuntu 24.04 paso a paso?

Entrás a Hetzner Cloud Console, creás un proyecto, y desde ahí “Add Server”. Elegís ubicación (Nuremberg, Falkenstein, Helsinki o Ashburn), imagen Ubuntu 24.04 LTS, y el tipo de instancia. Los planes compartidos de la línea CX arrancan en el orden de los 4-5 euros mensuales para 2 vCPU y 4 GB de RAM, aunque el precio exacto conviene verificarlo en su sitio porque la grilla cambia seguido.

Lo importante de esta pantalla: cargá tu clave SSH pública ANTES de crear el servidor. Si no lo hacés, Hetzner te manda la contraseña de root por mail y arrancás con autenticación por password, que es exactamente lo que querés evitar.

• Ubicación: desde Latinoamérica, la latencia a los datacenters europeos ronda los 200-250 ms. Para administración por SSH es tolerable; para servir usuarios finales de la región, no.
• Imagen: Ubuntu 24.04 LTS tiene soporte hasta 2029 y trae paquete oficial de Tailscale en el repo del fabricante.
• SSH keys: pegá el contenido de tu ~/.ssh/id_ed25519.pub. Si no tenés par de claves, generalo con ssh-keygen -t ed25519.
• Firewall de Hetzner: es una capa adicional a nivel red, independiente de UFW. Se puede usar para bloquear el 22 desde la infraestructura antes incluso de que el paquete llegue al servidor.

Primera conexión y hardening mínimo, en el orden que corresponde:

ssh root@TU_IP_PUBLICA
apt update && apt upgrade -y
adduser deploy
usermod -aG sudo deploy
rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy

Trabajar como root todo el tiempo es una costumbre que se paga cara. Creás el usuario sin privilegios, le copiás la clave, y desde ahí en adelante usás sudo. Cubrimos ese tema en detalle en proteger secretos en tu pipeline CI/CD.

Si tu público está en Argentina o la región y necesitás baja latencia real, un VPS europeo no es la respuesta: para eso conviene infraestructura local como la de donweb.com, que te ahorra los 200 ms de ida y vuelta al Atlántico. La receta de Tailscale que sigue funciona igual sobre cualquier VPS con Ubuntu.

¿Cómo instalar Claude Code en un VPS remoto?

La instalación son tres pasos: Node.js en una versión LTS reciente, el paquete de Claude Code por npm, y la autenticación desde un entorno sin navegador. Ese último punto es el que traba a casi todos, porque el flujo por defecto abre el navegador y en un servidor headless no hay navegador que abrir.

# Como usuario deploy, no como root
curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash -
sudo apt install -y nodejs
node --version

# Cliente de Claude Code
npm install -g @anthropic-ai/claude-code
claude --version

Instalar paquetes npm globales como root es una mala idea que además te deja archivos con permisos raros en el home. Si npm install -g te pide sudo, configurá un prefijo en el home del usuario (npm config set prefix ~/.npm-global) y agregá esa ruta al PATH. Es un minuto de trabajo que te ahorra media hora de permisos rotos después.

• Elegí Debian o Ubuntu LTS: son las distros donde el paquete de Node y el de Tailscale están mejor soportados. Con Alpine vas a pelear con musl y binarios nativos.
• Autenticación headless: al correr claude por primera vez te da una URL. La abrís en el navegador de tu máquina, completás el login y pegás el código de vuelta en la terminal del servidor.
• Verificá la sesión antes de seguir: un claude que arranca y responde es la señal de que la autenticación quedó persistida en el home del usuario. Si tenés que reautenticar en cada login, algo quedó mal en los permisos.
• Un usuario dedicado para el agente: no lo corras con el mismo usuario que administra el resto del servidor. Separar cuentas te da un límite claro de qué puede tocar.

La documentación oficial de Anthropic tiene el detalle fino de flags y variables de entorno, y conviene consultarla porque el CLI cambia seguido. Guías prácticas del setup completo hay varias: la de Virtua Cloud en español cubre la ejecución en VPS paso a paso, y la de 0xmega en Medium arma el circuito completo con tmux y acceso móvil.

¿Cómo instalar y conectar Tailscale en el servidor y en tu máquina?

La instalación en Ubuntu 24.04 es un script oficial de una línea, seguido de la autenticación por navegador. En el servidor corrés el instalador, levantás el daemon con tailscale up, copiás la URL que imprime, la abrís desde tu máquina local y aprobás el dispositivo. El mismo procedimiento se repite en tu notebook. Relacionado: elegir entre PM2 o Docker.

# En el VPS (como deploy, con sudo)
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

# Verificar la IP asignada
tailscale ip -4
# → 100.x.y.z

# Ver todos los nodos del tailnet
tailscale status

Desde tu máquina, la prueba de fuego antes de tocar nada del firewall:

ping 100.x.y.z
ssh [email protected]

¿Entraste? Perfecto. ¿No entraste? No cierres el puerto 22 bajo ningún concepto. Este es el punto exacto donde la gente se queda afuera de su propio servidor y termina reinstalando desde cero o pidiendo consola de rescate.

¿Conviene desactivar la expiración de claves del nodo?

Para un servidor que tiene que estar siempre accesible, sí. Por defecto Tailscale expira la clave del nodo cada cierto tiempo y te pide reautenticar; si eso pasa mientras el 22 público está cerrado, te quedás sin camino de entrada. En el panel de administración, sobre el nodo del VPS, está la opción de deshabilitar la expiración.

Es una decisión con un costo de seguridad, no gratis: una clave que no expira es una clave que sigue válida si alguien compromete el servidor. La alternativa razonable es dejarla sin expiración pero revisar la lista de dispositivos del tailnet cada tanto y borrar los que ya no uses. El tutorial de Raiola Networks sobre Tailscale en servidores VPS cubre este punto junto con la configuración de exit node.

¿Qué es una auth key y cuándo usarla?

Una auth key es un token pre-generado desde el panel de Tailscale que autoriza un dispositivo sin pasar por el navegador. Sirve para automatizar: tailscale up --authkey=tskey-... en un script de provisioning, en un Dockerfile o en cloud-init. Las hay efímeras (el nodo se borra del tailnet al desconectarse) y reutilizables.

Nunca la pegues literal en un script versionado. Va en una variable de entorno o en un gestor de secretos, porque quien tenga esa key puede meter un dispositivo propio dentro de tu red privada.

¿Cómo cerrar el puerto 22 y endurecer el firewall con UFW?

La regla clave es permitir SSH solo sobre la interfaz tailscale0 y denegarlo en el resto. UFW acepta reglas por interfaz, así que no hace falta enumerar rangos de IP: cualquier paquete que entre por Tailscale al puerto 22 pasa, cualquier otro se descarta. El orden de ejecución no es negociable: primero verificás el acceso por la IP 100.x, después cerrás.

sudo ufw default deny incoming
sudo ufw default allow outgoing

# SSH solo por la interfaz de Tailscale
sudo ufw allow in on tailscale0 to any port 22 proto tcp

# Si el server publica web
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

sudo ufw enable
sudo ufw status verbose

Fijate que no hay ningún ufw allow 22 genérico. Esa línea es la que arruina todo el esquema y la que aparece copiada en la mitad de los tutoriales de hardening que andan dando vueltas.

Para comprobar el resultado desde afuera, un escaneo simple contra la IP pública: En bases de datos en Hetzner sin sorpresas profundizamos sobre esto.

# Desde otra máquina, contra la IP PÚBLICA
nmap -Pn -p 22,80,443 TU_IP_PUBLICA
# 22/tcp filtered ssh ← lo que querés ver
# 80/tcp open http
# 443/tcp open https

Ese filtered en el 22 es el objetivo del ejercicio. Desde internet el servicio no responde; desde tu tailnet entrás normal.

Un detalle que se pasa por alto: el puerto donde escucha Claude Code, si usás alguna interfaz web o un servicio auxiliar, tampoco se abre al mundo. Se accede por la IP de Tailscale igual que SSH. La regla es simple: nada de administración se publica en la IP pública, ni siquiera “un ratito para probar”.

¿Sigue teniendo sentido instalar fail2ban?

Si el 22 quedó cerrado al mundo, fail2ban sobre SSH pierde casi toda su razón de ser: no hay tráfico público que banear. Donde sí sirve es sobre los servicios que dejaste expuestos, típicamente el 80 y el 443, con jails para nginx o para el login de tu aplicación. Instalarlo “por las dudas” y dejarlo solo con la jail de sshd es puro placebo.

¿Cómo conectarse a Claude Code desde el celular o cualquier dispositivo?

Instalás Tailscale en el celular, iniciás sesión con la misma cuenta, y el teléfono pasa a ser un nodo más del tailnet con acceso a la IP 100.x del servidor. Desde ahí, cualquier cliente SSH del teléfono se conecta como si estuvieras en la misma red local. No hace falta abrir ningún puerto ni configurar port forwarding en ningún lado.

El flujo típico es este. Arrancás una tarea en la notebook dentro de una sesión de tmux, cerrás la máquina, salís. Media hora después, desde el celular, abrís el cliente SSH, hacés tmux attach y ves la salida en vivo de lo que quedó corriendo. Escribís una instrucción nueva si hace falta, cerrás la app, y el agente sigue. Lo explicamos a fondo en pipelines de integración continua modernos.

• Clientes SSH móviles: Termius tiene versión para Android e iOS, y en iOS también se usan clientes como Blink o Prompt. Cualquiera sirve mientras soporte claves y sesiones persistentes.
• VS Code Remote SSH: desde la notebook, apuntás la extensión a la IP de Tailscale y editás archivos del servidor como si fueran locales, con el agente corriendo en la misma máquina.
• La clave SSH también va en el celular: generás un par de claves en el teléfono y agregás la pública al authorized_keys del servidor. Copiar la clave privada de la notebook al celular es la opción cómoda y la peor idea.
• Tipear en el celular es incómodo: seamos honestos, el teléfono sirve para monitorear, aprobar un paso o dar una instrucción corta. No para escribir código.

Existe una variante más agresiva del mismo patrón: exponer un asistente autoalojado sin ningún puerto público, todo por la red de Tailscale, como documenta esta guía de self-hosting con cero puertos públicos. El principio es el mismo que acá: la superficie de administración no vive en internet.

¿Se puede automatizar el setup completo con Claude Code?

Sí, y es justamente lo que hizo circular esta receta. Claude Code es la herramienta CLI de Anthropic que corre en la terminal y ejecuta comandos, lee archivos y edita configuración con tu autorización. Hay prompts publicados en GitHub que describen el setup completo (usuario sin privilegios, claves SSH, Tailscale, UFW, actualizaciones automáticas) para que el modelo lo ejecute paso a paso sobre un servidor recién creado.

Los dos repos que más se compartieron son deniurchak/claude-vps-setup-prompt y rasha-hantash/claude-vps-setup. Ambos apuntan a lo mismo: en vez de seguir un tutorial de veinte pasos a mano, le pasás el prompt al asistente y lo dejás ejecutar, revisando cada comando antes de aprobarlo.

Ahora bien, hay que decirlo: dejar un agente con permisos de sudo en un servidor de producción no es una decisión trivial. Le pedís que “limpie los logs viejos”, interpreta el pedido con más entusiasmo del esperado, borra algo que no correspondía, y te enterás dos días después cuando falla un backup. Andá con revisión de comandos activada, y si el server importa, probá primero en uno descartable.

• Secretos por variables de entorno, nunca por historial: las auth keys de Tailscale y los tokens de API van en .env o en el gestor de secretos, no tipeados en la terminal donde quedan en ~/.bash_history.
• Un usuario dedicado para el agente: con sudo acotado a lo que necesita, no sudo total.
• Revisión de comandos antes de ejecutar: el modo desatendido está bueno para un sandbox, no para el servidor donde corre tu aplicación.
• Todo en git: si el agente toca configuración, que el directorio esté versionado. Un git diff te muestra qué cambió.

¿Cómo dejar Claude Code corriendo 24/7 con tmux y MCP?

tmux es lo que mantiene la sesión viva cuando cerrás SSH. Sin tmux, el proceso del agente cuelga de tu terminal: se corta la conexión, se muere el proceso y perdés el trabajo a medio hacer. Con tmux, el agente corre dentro de una sesión que pertenece al servidor y vos te enganchás y desenganchás sin afectarla.

# Crear la sesión y arrancar el agente adentro
tmux new -s claude
claude

# Detach: Ctrl+b, después d
# Reconectar desde cualquier dispositivo
tmux attach -t claude

# Ver sesiones activas
tmux ls

La segunda pieza son los MCP servers, el mecanismo con el que el agente accede a herramientas externas: una base de datos, un sistema de archivos remoto, una API interna, un repositorio. En vez de que el modelo adivine el estado de tu infraestructura, le das un canal estructurado para consultarla. Ahí es donde el setup deja de ser “una terminal con IA” y pasa a ser algo parecido a un operador.

• Una sesión de tmux por proyecto: nombrala con el nombre del repo. Cuando tengas cuatro cosas corriendo vas a agradecer no tener todo en una sola ventana.
• MCP con permisos mínimos: si le das acceso a la base, que sea con un usuario de solo lectura salvo que necesite escribir. Un agente con credenciales de admin sobre producción es exactamente el escenario que no querés.
• Logs de la sesión a un archivo: tmux pipe-pane guarda todo lo que pasó por la terminal. Si algo salió mal a las tres de la mañana, ahí está el registro.
• Webhooks como disparador: un endpoint que recibe un evento (un deploy fallido, una alerta) y despierta una tarea del agente. Útil, pero acá conviene ir despacio: automatizar la respuesta a incidentes sin supervisión es cómo se convierte un problema chico en uno grande.

Un matiz sobre el “24/7”: el agente no está pensando todo el tiempo, está esperando. La sesión persiste, pero el trabajo real ocurre cuando vos le pedís algo o cuando un disparador lo activa. Habría que ver cuánto de la promesa de “servidor autogestionado” se sostiene en la práctica más allá de tareas acotadas y bien definidas.

Esto se conecta con Hetzner hands-off setup, donde cubrimos el tema en detalle.

Esto lo cubrimos en profundidad en nuestro artículo sobre VPS seguro con Tailscale.

¿Quién usa este setup en producción y qué resultados tuvo?

El caso más citado es el de Pieter Levels, conocido como levelsio, que hace más de un año desarrolla sus proyectos con este esquema: VPS propio, agente corriendo en el servidor, sin depender del entorno local. Su flujo de trabajo se volvió la referencia informal del patrón, y buena parte de las guías que circulan hoy son variantes de lo que él mostró públicamente.

El stack que se repite en las guías es bastante consistente: un VPS de entrada de 4-7 dólares, Tailscale para el acceso, tmux para la persistencia, y alguna herramienta de automatización tipo n8n para los disparadores. Nada exótico. Lo que cambió no es la tecnología sino quién ejecuta los comandos.

• Mirá CPU y RAM bajo carga real: el agente pidiendo un build completo mientras corre tu aplicación es donde un VPS de 2 GB se queda corto. Un htop abierto la primera semana te dice si el plan te queda chico.
• Los servicios se cuelgan: un proceso que quedó zombie después de una tarea interrumpida no se arregla solo. Vale la pena un chequeo periódico y un reinicio automático por systemd.
• Backups aparte del servidor: si el agente puede escribir en el disco, el backup no puede vivir en el mismo disco. Snapshot del proveedor o copia a otro destino, pero afuera.
• El costo escala con el uso, no con el server: el VPS es fijo, la suscripción también, pero si pasás a consumo por API el gasto varía según cuánto trabaje el agente.

Una advertencia sobre las cifras que circulan: los USD 25-30 mensuales son el piso del stack básico. No incluyen almacenamiento adicional, backups gestionados, ni el salto a un plan superior cuando el proyecto crece. Tomalo como orden de magnitud y no como presupuesto cerrado.

¿Cómo mantener el servidor sin intervención manual?

El mínimo indispensable son las actualizaciones de seguridad automáticas, que en Ubuntu 24.04 se resuelven con unattended-upgrades. El paquete viene preinstalado en la imagen de servidor pero conviene reconfigurarlo para confirmar que aplique los parches de seguridad y reinicie cuando haga falta.

sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
sudo systemctl status unattended-upgrades

Con eso los parches de seguridad se aplican solos. Lo que no resuelve es el reinicio pendiente cuando se actualiza el kernel: el archivo /etc/apt/apt.conf.d/50unattended-upgrades tiene una directiva Automatic-Reboot que está desactivada por defecto, y si nunca reiniciás, seguís corriendo el kernel viejo.

Ojo con un efecto secundario del reinicio automático: te reinicia el servidor y con él se van las sesiones de tmux. Si dejaste el agente corriendo algo largo, se corta. Conviene programar la ventana de reinicio en un horario donde no haya nada crítico en vuelo. Cubrimos ese tema en detalle en GitHub Actions vs herramientas tradicionales.

Después está la parte que Tailscale no cubre. Tailscale te resuelve el acceso, no el monitoreo: no te avisa si se llenó el disco, si un proceso se comió la RAM o si tu aplicación devuelve 500. Para eso necesitás otro stack, sea un agente de métricas, un uptime checker externo o alertas de logs. Confundir “tengo acceso seguro” con “tengo el servidor monitoreado” es un error clásico. Lo explicamos a fondo en orquestar procesos en producción.

Errores comunes al montar este stack

• Cerrar el 22 antes de probar el acceso por Tailscale: el clásico. Corrés ufw enable con la regla de deny, se corta tu sesión actual, y el único camino de vuelta es la consola web de rescate del proveedor. Probá primero ssh [email protected] en una terminal nueva, con la sesión original abierta.
• Dejar un ufw allow 22 genérico junto a la regla de tailscale0: UFW aplica ambas y el puerto sigue abierto al mundo. Revisá con ufw status numbered y borrá la regla sobrante con ufw delete N.
• Dejar la expiración de clave activa en el nodo del VPS: vence la key, el nodo sale del tailnet, y como el 22 público está cerrado te quedaste sin entrada. Deshabilitala en el panel para ese nodo puntual.
• Pegar la auth key de Tailscale en un script versionado: queda en el historial de git para siempre, aunque después la borres del archivo. Si ya pasó, revocá la key desde el panel y generá una nueva.
• Correr el agente sin tmux: se corta el SSH, se muere el proceso, y la tarea larga que dejaste andando quedó a mitad de camino sin registro de qué alcanzó a hacer.
• Dar sudo sin restricciones al agente y correrlo en modo desatendido: un comando mal interpretado sobre un servidor de producción no se deshace con Ctrl+Z. Revisión activada y, si se puede, un servidor de prueba.
• Suponer que el firewall del proveedor y UFW son lo mismo: el firewall de Hetzner Cloud filtra antes de llegar a la VM, UFW filtra adentro. Si configurás uno y te olvidás del otro, la regla que creés que aplica probablemente no aplique.

Preguntas Frecuentes

¿Cómo instalo Claude Code en un VPS remoto?

Instalás Node.js en versión LTS, después el paquete del CLI con npm install -g @anthropic-ai/claude-code, y al correrlo por primera vez completás la autenticación pegando en el navegador de tu máquina la URL que imprime la terminal. Hacelo con un usuario sin privilegios, no con root. Si npm te pide sudo para instalar global, configurá un prefijo en el home antes de seguir.

¿Cuánto cuesta tener Claude Code corriendo en un VPS?

El orden de magnitud es USD 25-30 por mes: entre 4 y 7 dólares del VPS de entrada más los USD 20 de la suscripción Claude Pro. No entran ahí los extras habituales como backups gestionados, almacenamiento adicional o un plan más grande si el proyecto crece. Si en vez de suscripción usás la API por consumo, el gasto varía según cuánto trabaje el agente.

¿Qué requisitos de hardware tiene un VPS para Claude Code?

Con 2 vCPU y 2 GB de RAM arranca, y 4 GB es lo recomendable para proyectos con builds o tests. No necesitás GPU: el modelo corre en la infraestructura de Anthropic y el servidor solo ejecuta el cliente CLI sobre Node.js. Lo que consume recursos es lo que el agente ejecuta, no el agente en sí.

¿Cómo accedo a Claude Code desde el celular sin abrir puertos?

Instalás Tailscale en el teléfono con la misma cuenta y te conectás por SSH a la IP 100.x del servidor desde un cliente como Termius. El teléfono queda como un nodo más del tailnet, así que no hace falta abrir nada al público. Una vez adentro, tmux attach te devuelve la sesión del agente tal cual la dejaste.

¿Es seguro dejar Claude Code corriendo en un servidor de producción?

Depende de los permisos que le des. Con un usuario dedicado, sudo acotado y revisión de comandos activada, el riesgo es comparable al de cualquier operador con acceso. Con sudo total en modo desatendido sobre un server que te importa, no. La recomendación práctica es empezar en un servidor descartable hasta entender qué tipo de comandos ejecuta ante cada pedido.

¿Qué pasa si se cae el servicio de Tailscale? ¿Pierdo el servidor?

Las conexiones ya establecidas siguen funcionando, porque el túnel WireGuard es directo entre los dos dispositivos y no pasa por Tailscale. Lo que se cae es la capacidad de autorizar dispositivos nuevos o renovar claves. Como red de contención, dejá siempre disponible la consola VNC de rescate de tu proveedor: es acceso fuera de banda, independiente de la red.

¿Puedo usar esta configuración con un VPS que no sea de Hetzner?

Sí. Nada de este esquema depende de Hetzner: Tailscale se instala igual en cualquier servidor Ubuntu, Debian, Rocky o Alpine, y UFW funciona en cualquier distribución con Netfilter. Lo único que cambia entre proveedores es la interfaz para crear la máquina y si tienen o no una capa de firewall propia a nivel red.

¿Cuánto cuesta Tailscale?

Tailscale tiene un plan gratuito personal que cubre de sobra el caso de un VPS con unos pocos dispositivos, y planes pagos para equipos con funciones de administración centralizada. Los límites exactos de dispositivos y usuarios del plan gratis conviene chequearlos en su sitio oficial, porque los ajustaron varias veces.

¿Tailscale reemplaza al firewall?

No. Tailscale te da un canal privado de acceso, pero el firewall sigue siendo el que decide qué puertos escuchan y desde dónde. Los dos trabajan juntos: Tailscale provee el camino, UFW define que SSH solo acepte tráfico por ese camino. Sin la regla de UFW, el puerto 22 sigue abierto a internet aunque tengas Tailscale andando.

Conclusión

Lo que cambió acá no es la criptografía ni el firewall, que son los de siempre. Cambió el costo de armarlo: lo que antes era una tarde de configurar WireGuard peer por peer y depurar reglas de iptables, hoy son un script de instalación, un login con Google y una regla de UFW por interfaz. Y sobre esa base se apoyó lo nuevo: el servidor dejó de ser solo un lugar donde corre tu aplicación y pasó a ser el lugar donde vive tu entorno de trabajo, con el agente adentro.

El orden de ejecución sigue siendo el mismo y no es negociable: creás el VPS con clave SSH cargada, instalás Tailscale en servidor y cliente, verificás que entrás por la IP 100.x, recién ahí cerrás el 22 con UFW, y cerrás con unattended-upgrades. Encima de eso, si querés el setup completo, sumás Node.js, el CLI de Anthropic y tmux. Media hora larga, USD 25-30 al mes, y superficie de administración cero desde internet.

Lo que conviene seguir de acá en adelante son dos cosas. Una es cuánto se puede delegar de verdad sin supervisión: por ahora el patrón anda bien con tareas acotadas y se pone incómodo con acceso desatendido a producción. La otra es lo que este stack sigue sin resolver: monitoreo, backups y latencia. Si tus usuarios están en la región, un servidor europeo te suma 200 ms en cada request, y ninguna VPN mesh arregla la distancia física.

Fuentes

• Claude Code on a VPS: the complete setup – Guía de 0xmega sobre seguridad, tmux y acceso móvil
• Ejecutar Claude Code en un VPS – Tutorial en español con el paso a paso de instalación
• Self-hosting con Tailscale y cero puertos públicos – Caso práctico de asistente autoalojado sin exposición a internet
• Instalar y configurar Tailscale en un servidor VPS – Guía en español con exit node y expiración de claves
• deniurchak/claude-vps-setup-prompt – Prompt público de setup de VPS seguro para Claude Code
• Configurar Tailscale, red VPN segura – Tutorial en español de RedesZone