Migrar API a Hetzner: qué servidor elegir en 2026

En pocas palabras: Para migrar una API de producción con Rust, PostgreSQL, Valkey y Caddy, un desarrollador eligió en octubre de 2026 el servidor CX23 de Hetzner Cloud (2 vCPU, 4 GB RAM, 40 GB disco) a USD 6,49 mensuales, tras medir que todo el stack consumía apenas 1 GB de RAM en el servidor anterior.

Un desarrollador migró la API de producción de su empresa (stack con Rust, PostgreSQL, Valkey y Caddy corriendo bajo Docker Compose) desde un VPS genérico a Hetzner Cloud, y documentó cada decisión en octubre de 2026: terminó eligiendo un servidor CX23 de 2 vCPU y 4 GB a USD 6,49 mensuales, después de medir que todo el stack apenas usaba 1 GB de RAM en el servidor viejo.

Hetzner Cloud es el servicio de infraestructura virtual de la empresa alemana Hetzner Online, con servidores de CPU compartida (series CX y CPX) y CPU dedicada (serie CCX), facturación mensual, firewall perimetral gestionado desde consola y data centers en Alemania (Nuremberg, Falkenstein) y Finlandia (Helsinki), todos dentro de la misma zona de red eu-central. Para quien quiere migrar API a Hetzner, el primer paso no es técnico: es elegir bien el tipo de servidor.

Qué tipo de servidor de Hetzner conviene para una API en producción

Para una API chica en producción, lo que mejor rinde en precio por GB de RAM es la familia Cost-Optimized (CX o CAX), siempre que tu imagen Docker esté compilada para la arquitectura correcta. Hetzner divide su catálogo en tres familias y la diferencia entre ellas no es cosmética: determina cuánto pagás y qué tan predecible es tu CPU.

Según el tutorial publicado en dev.to, así se veía el catálogo en Helsinki en octubre de 2026:

Familia	Serie	Specs ejemplo	Precio/mes	Para qué sirve
Cost-Optimized (shared)	CX23	2 vCPU, 4 GB, 40 GB	USD 6,49	Servicios chicos, side projects
Regular Performance (shared)	CPX22	2 vCPU, 4 GB, 80 GB	USD 22,99	Mismo trabajo, CPU más consistente
General Purpose (dedicated)	CCX13	2 vCPU dedicados, 8 GB, 80 GB	USD 50,49	Carga sostenida: builds, bases de datos con mucho tráfico

Ojo con un detalle que se pierde fácil en el checkout: la IPv4 pública se cobra aparte, USD 0,60 mensuales, en los tres casos. Y si tu imagen está armada para amd64, no podés usar la variante Arm64 (CAX) sin reconstruir el contenedor. Antes de decidir, corré docker manifest inspect <imagen> (reemplazando <imagen> por el nombre de tu imagen) para ver qué plataformas soporta tu build.

Cómo medir cuánta RAM y CPU necesita realmente tu stack antes de comprar

Medís con dos comandos antes de gastar un centavo: docker stats --no-stream para ver qué usa cada contenedor, y free -h para la memoria total del sistema. En el caso documentado, el servidor viejo mostraba que Rust, Postgres, Valkey y Caddy juntos consumían alrededor de 1 GB de RAM. Nada del otro mundo.

El tema es que Ubuntu solo, recién booteado y sin ningún contenedor corriendo, ya usa unos 500 MB. Esa cifra cambia todo el cálculo de qué servidor elegir.

Opción	vCPU / RAM / disco	Precio + IPv4	Veredicto
CPX02	1 / 1 GB / 20 GB	USD 7,49 + 0,60	Demasiado chico: todo junto desborda a swap
CPX12	1 / 2 GB / 40 GB	USD 13,49 + 0,60	Justo de RAM, el doble de precio que CX23
CX23	2 / 4 GB / 40 GB	USD 6,49 + 0,60	Elegido: 4x de margen, el más barato que entra
CPX22	2 / 4 GB / 80 GB	USD 22,99 + 0,60	Plan B si el CX23 sigue sin stock
CCX13	2 dedicado / 8 GB / 80 GB	USD 50,49 + 0,60	Mucho más de lo que pide una API en reposo

Con esos números, el CX23 queda con cuatro veces más RAM de la que necesita el stack. Ese colchón importa cuando Postgres hace un vacuum pesado o cuando llega un pico de tráfico inesperado. Los precios cambian seguido, así que conviene chequear la consola de Hetzner antes de decidir, no esta tabla con datos de octubre de 2026.

Cómo decidir entre CX, CPX y CCX sin copiar la elección de otro

El caso documentado resuelve bien para una API chica que pasa la mayor parte del día en reposo, pero la elección no se traslada automáticamente a cualquier escenario. El propio tutorial explica qué es el CPU steal (cuando un vecino en el mismo host físico consume tu porción de CPU compartida) y a partir de esa idea se pueden armar tres criterios concretos para decidir sin medir todavía:

• Si tu servicio tiene picos cortos y mucho tiempo de inactividad —una API interna, un side project, un backend que recibe tráfico parejo durante el día— el steal rara vez se nota, y la familia Cost-Optimized alcanza.
• Si corrés algo que exige CPU de forma sostenida —compilaciones, workers de cola, una base de datos con escrituras constantes— el steal sí puede notarse, y ahí la diferencia de precio hacia CCX (dedicado) se justifica.
• Si la disponibilidad limitada de Cost-Optimized te deja sin stock justo cuando necesitás crear el servidor, Regular Performance (CPX) funciona como punto medio: mismo modelo de CPU compartida, hardware más nuevo, sin la lotería de disponibilidad por ubicación.

Ejemplo hipotético: pensemos en un equipo que corre una API de facturación para comercios en Argentina, con tráfico bajo durante la madrugada y picos de unos minutos cada vez que vence un plazo impositivo. Si ese pico es corto y el resto del día el servidor está casi en reposo, un CX23 con el margen de RAM que muestra la tabla anterior probablemente lo absorba sin pagar de más por CPU dedicada. Lo que define si alcanza o no es el mismo dato que usó el autor del tutorial original: cuánto consume el stack en el momento de mayor carga, no el promedio del día.

Por qué los servidores Cost-Optimized de Hetzner aparecen como “limited availability”

Los tipos Cost-Optimized se reservan desde un pool de hosts físicos por ubicación, y cuando ese pool se llena, el tipo desaparece del catálogo en esa región hasta que se libera capacidad. No es un bug ni un error de carga de la consola.

¿Y qué pasó en el caso documentado? El autor configuró el CX23 en Helsinki, volvió unos minutos después a confirmar la creación y toda la fila aparecía gris, sin posibilidad de seleccionarla. Tenía tres salidas:

• Cambiar de ubicación. Nuremberg (nbg1), Falkenstein (fsn1) y Helsinki (hel1) comparten la zona de red eu-central, con latencia similar hacia Europa, así que el tipo suele estar disponible en alguna de las tres.
• Esperar y reintentar. La capacidad se libera y se agota durante el día; el CX23 en Helsinki volvió a aparecer más tarde.
• Subir a la familia CPX si no podés esperar y el precio te cierra.

Hay una consecuencia que no es obvia hasta que te pasa: una vez que conseguiste un tipo escaso, borrar ese servidor para corregir un error de configuración es riesgoso, porque quizás no consigas otro igual. Por eso, si algo salió mal en la configuración inicial, conviene arreglarlo con el servidor corriendo en vez de recrearlo de cero.

Qué es una SSH key pair y cómo se configura en Hetzner

Una SSH key pair es dos mitades de un mismo objeto matemático: la clave privada se queda en tu laptop y nunca sale de ahí, y la clave pública se copia a cada servidor al que querés entrar. El servidor nunca conoce tu clave privada; en cada conexión te pide firmar un valor único, y si la firma coincide con la clave pública que tiene guardada, confirma que sos vos sin que la clave privada haya viajado por la red.

Hay dos pares de claves distintos en juego acá. El host key pertenece al servidor y prueba que es quien dice ser (la primera vez que te conectás, SSH te muestra su huella digital y te pregunta si confiás: eso se llama TOFU, trust on first use). El user key es tuyo y prueba que podés loguearte como ese usuario.

Para crear el par:

• ssh-keygen -t ed25519 genera una clave moderna de curva elíptica, corta y sin parámetros débiles que puedan salir mal, a diferencia de las RSA viejas.
• -f ~/.ssh/hetzner_ed25519 le pone un nombre de archivo propio, así perder esta clave no afecta a las de otros proveedores.
• -C hetzner-api agrega una etiqueta para reconocerla después en authorized_keys.

Cuando pegás la clave pública en Hetzner → Security → SSH keys y la elegís en la pantalla de creación del servidor, Hetzner la escribe en /root/.ssh/authorized_keys y, como efecto colateral, no configura ninguna contraseña de root. Nada de password, solo la clave.

Qué es la Primary IP en Hetzner y por qué conviene desactivar el auto delete

La Primary IP es la dirección pública de un servidor en Hetzner Cloud, un recurso separado que se crea junto con la máquina pero que tiene vida propia. La IPv4 se factura aparte, unos USD 0,60 por mes, porque el stock mundial de IPv4 se agotó. La IPv6 viene gratis con un bloque /64 completo, es decir 2 elevado a la 64 direcciones, de las cuales el servidor usa la primera por convención.

Cada Primary IP tiene un switch de auto delete. Prendido, la dirección se libera cuando borrás el servidor y probablemente no la recuperes más. Apagado, la dirección queda guardada en tu proyecto, lista para asignarse a un servidor de reemplazo.

¿Por qué importa en producción? Tres razones concretas: tu DNS apunta a esa IP y cambiarla implica esperar a que se propague (algo que se explica mejor cuando entra el tema de TTLs); algunos servicios externos, como tokens de object storage o webhooks de pagos, filtran por IP de origen; y si el servidor se rompe de forma irrecuperable, podés borrarlo y crear uno nuevo con la misma dirección. Esa dirección fija es tu salvavidas.

Cómo configurar el Cloud Firewall de Hetzner antes de crear el servidor

El Cloud Firewall de Hetzner filtra el tráfico antes de que llegue a tu VM, mientras que un firewall de host como ufw filtra adentro de la VM. La diferencia no es teórica: cuando un contenedor publica un puerto (ports: ["443:443"]), Docker escribe sus propias reglas NAT que mandan el paquete directo al contenedor antes de que llegue a la cadena que controla ufw. Resultado: ufw deny 443 no bloquea un puerto publicado por Docker, y hay bastante gente ahí afuera con una base de datos expuesta a internet mientras ufw status dice que todo está cerrado.

Por eso el Cloud Firewall es el perímetro real, porque no se puede saltar desde dentro de la VM. Las reglas documentadas en el caso real:

Protocolo	Puerto	Para qué
TCP	2222	SSH en puerto no estándar
TCP	22	SSH de respaldo para redes que bloquean puertos raros
TCP	80	Desafío HTTP-01 de Let’s Encrypt y redirección a HTTPS
TCP	443	Tráfico de la API
UDP	443	HTTP/3, porque QUIC corre sobre UDP
ICMP	—	Ping y path-MTU discovery

Nada de reglas de salida en esa lista, y no es un olvido: ambos firewalls son stateful, rastrean conexiones, así que las respuestas a algo que tu servidor inició (bajar paquetes, pedir un certificado) entran solas. Sin reglas de salida explícitas, Hetzner deja pasar todo el tráfico saliente. Y los puertos 5432 (Postgres) y 6379 (Valkey) ni aparecen en la tabla, porque nunca se publican afuera del contenedor.

¿Por qué dos puertos de SSH? El 22 recibe un flujo constante de bots probando contraseñas. Moverlo al 2222 no es seguridad real (un escaneo de puertos lo encuentra en segundos), pero baja ese ruido casi a cero y mantiene los logs legibles. La seguridad de fondo es el login solo con clave.

Errores comunes al migrar API a Hetzner

• Confiar en ufw como única defensa. Si publicás puertos con Docker, ufw no los ve: el Cloud Firewall de Hetzner es el que realmente protege.
• Borrar un servidor Cost-Optimized para corregir un error. Si el tipo tiene disponibilidad limitada, puede que no consigas otro igual en esa ubicación.
• Dejar el auto delete prendido en la Primary IP. Perdés la dirección justo cuando más la necesitás, en medio de un incidente.
• Elegir CAX (Arm64) sin chequear la arquitectura de la imagen Docker. Si tu build es amd64, el contenedor no arranca.
• Confundir el precio del servidor con el costo total. La IPv4 suma USD 0,60/mes aparte, y si usás varios servidores esa cifra se acumula.

Para equipos en Argentina que recién arrancan a mover infraestructura a Europa, vale la aclaración: si lo que necesitás es hosting o dominios con soporte en español y facturación local, donweb.com sigue siendo una opción más simple que armar todo este setup desde cero. Para una API con requisitos específicos de stack, como la de este caso, Hetzner tiene sentido igual.

Preguntas Frecuentes

¿Qué tipo de servidor de Hetzner conviene para una API en producción?

Para una API chica con tráfico moderado, el CX23 de la familia Cost-Optimized (2 vCPU, 4 GB, 40 GB) a USD 6,49 mensuales suele sobrar, siempre que tu imagen Docker sea compatible con la arquitectura disponible. Medí primero con docker stats cuánto usa tu stack real antes de decidir el tamaño.

¿Cuál es la diferencia entre Cost-Optimized, Regular Performance y Dedicated en Hetzner?

Cost-Optimized (CX/CAX) usa CPU compartida sobre hardware más viejo y es la opción más barata por GB de RAM, pero con disponibilidad limitada. Regular Performance (CPX) también es compartida pero con hardware más nuevo, a un precio más alto. General Purpose (CCX) tiene vCPUs dedicadas, ideal para carga sostenida como builds o bases de datos con mucho tráfico.

¿Por qué los servidores CX de Hetzner aparecen como no disponibles?

Porque Hetzner asigna los tipos Cost-Optimized desde un pool limitado de hosts físicos por ubicación, y cuando ese pool se completa, el tipo desaparece del catálogo en esa región hasta que se libera capacidad. La solución práctica es cambiar de ubicación dentro de la misma zona de red, esperar y reintentar más tarde, o subir a la familia CPX.

¿Cómo funciona el firewall de Hetzner Cloud con Docker?

El Cloud Firewall de Hetzner filtra el tráfico antes de que llegue a la VM, por lo que no se puede evitar desde adentro del contenedor. Esto importa porque Docker escribe sus propias reglas NAT para los puertos publicados, que pueden saltarse a ufw (el firewall interno), dejando puertos expuestos aunque ufw diga que están cerrados.

¿Qué es la Primary IP en Hetzner Cloud y por qué conviene desactivar el auto delete?

La Primary IP es la dirección pública asignada a un servidor de Hetzner Cloud, con la IPv4 facturada aparte (unos USD 0,60/mes) y un bloque IPv6 /64 gratuito. Conviene apagar el auto delete en producción porque el DNS apunta a esa dirección, algunos servicios la allowlistean, y permite recrear un servidor roto manteniendo la misma IP.

Conclusión

Elegir el servidor correcto en Hetzner no es solo mirar la tabla de precios: implica medir el consumo real del stack, entender que los tipos más baratos pueden no estar disponibles en el momento justo, y dejar configurados el firewall y la Primary IP antes de que el servidor exista. El caso documentado terminó con un CX23 a USD 6,49 mensuales cubriendo cuatro veces el consumo real del stack, con la Primary IP protegida de auto delete y un Cloud Firewall que no depende de lo que pase dentro de los contenedores.

Lo que no está resuelto todavía, y queda para la siguiente parte de la serie, es el hardening del sistema operativo y la configuración puntual de cada servicio. Si estás evaluando esta misma migración, el criterio más útil antes de gastar un centavo es correr docker stats --no-stream en tu servidor actual: ese número, no el catálogo de Hetzner, es el que debería definir qué tipo de servidor comprás. Y si tu patrón de tráfico tiene picos sostenidos en vez de picos cortos, ese mismo número te dice cuándo conviene saltar directo a CPX o CCX en vez de arrancar por el más barato.

Fuentes

• Moving a production API to Hetzner, part 1 – dev.to, tutorial original con los pasos, precios y configuración completos
• RFC 5737 – IETF, rango de direcciones IPv4 reservadas para documentación
• RFC 3849 – IETF, rango de direcciones IPv6 reservadas para documentación