Introducción

Desplegar aplicaciones en contenedores Docker es, hoy en día, el estándar de facto para equipos de desarrollo y administradores de sistemas. La promesa de empaquetar una aplicación con todas sus dependencias, bibliotecas y configuraciones para que se ejecute de manera idéntica en cualquier entorno ha transformado la forma en que concebimos el ciclo de vida del software. Sin embargo, una vez que el código está listo y la imagen construida, surge la pregunta inevitable: ¿dónde lo ejecutamos? La elección del proveedor de infraestructura se convierte en el siguiente gran desafío, especialmente cuando los costos de los hiperescaladores tradicionales como AWS, Google Cloud o Azure empiezan a escalar de forma agresiva a medida que crecen los proyectos.

Es en este punto donde Hetzner, un proveedor alemán con más de dos décadas de trayectoria, ha ganado una tracción notable en la comunidad técnica. Su propuesta de valor es directa y atractiva: ofrecer hardware dedicado y cloud a una fracción del coste de la competencia, manteniendo un rendimiento sobresaliente. Para un desarrollador independiente, una startup en fase inicial o un equipo que busca optimizar márgenes, la diferencia entre pagar 50 euros y 300 euros al mes por recursos equivalentes es un factor decisivo que puede determinar la viabilidad de un proyecto. Pero, ¿es esta la opción correcta para tu caso?

A lo largo de este texto, analizaremos en profundidad cómo aprovechar Hetzner para proyectos con Docker. No nos limitaremos a enumerar las características del panel de control o a repetir los precios de la web oficial. Nuestro objetivo es explorar la fricción real que existe al migrar una arquitectura de contenedores a este proveedor. Hablaremos de las diferencias sustanciales entre su servicio de Cloud (instancias virtualizadas) y sus servidores dedicados (bare metal), y cómo esta elección impacta directamente en el rendimiento de Docker, especialmente cuando se implementan orquestadores ligeros como Docker Swarm o incluso Kubernetes.

La utilidad práctica de esta guía radica en comprender que el ahorro económico en Hetzner no viene exento de responsabilidades adicionales. A diferencia de las soluciones gestionadas de los grandes proveedores, donde el plano de control es gestionado por la plataforma, en Hetzner serás tú quien asuma la operación, el mantenimiento del sistema operativo, la seguridad del núcleo y la correcta configuración de la red entre contenedores. Esto no es algo negativo; de hecho, para muchos, es una ventaja que permite un control total del stack y un aprendizaje técnico invaluable.

Analizaremos también cómo su red interna privada (Network) puede configurarse para permitir la comunicación entre nodos de Docker con baja latencia sin incurrir en costos de transferencia de datos, un aspecto crucial que a menudo se pasa por alto y que puede arruinar la factura a final de mes. A lo largo del artículo, exploraremos escenarios típicos: desde el despliegue de una aplicación en un solo servidor con `docker-compose` hasta arquitecturas multi-nodo más complejas, sopesando los pros y los contras de cada aproximación. El objetivo es que, al finalizar, tengas una hoja de ruta clara para decidir si Hetzner es el hogar adecuado para tus contenedores y, si lo es, cómo hacerlo de manera eficiente y segura desde el primer día.

Qué es

Hetzner es, en esencia, un proveedor de infraestructura en la nube y servidores dedicados con sede en Alemania, fundado en 1997. Para el desarrollador medio, se ha ganado una reputación casi legendaria por un motivo muy concreto: ofrece hardware de alta calidad y ancho de banda generoso a una fracción del coste que pedirían los gigantes del sector. Pero, ¿qué significa esto realmente cuando hablamos de proyectos con Docker?

Para entenderlo, hay que separar el grano de la paja. No es un "servicio de hosting para contenedores" como podría serlo una plataforma PaaS (Plataforma como Servicio) tipo Heroku o Railway. Hetzner no es un panel mágico donde haces *push* y tu contenedor se despliega. Es la materia prima: máquinas virtuales (llamadas CPX o CX) y servidores físicos dedicados (AX y EX) donde tú tienes control total del sistema operativo y, por tanto, de tu motor Docker.

La diferencia fundamental radica en el modelo de responsabilidad. Con Hetzner, tú eres el administrador del núcleo. Tú instalas Docker Engine, docker-compose o Kubernetes. Tú gestionas las actualizaciones del sistema base, el firewall y la persistencia de datos. A cambio de esa responsabilidad, obtienes un control absoluto sobre la configuración y un ahorro económico sustancial.

Un ejemplo práctico: un proyecto con Docker Compose que incluye un contenedor de Nginx, una API en Node.js y una base de datos PostgreSQL. En una plataforma PaaS, cada uno de esos servicios consumiría una cuota de memoria separada y a menudo tendrías que pagar por características "pro" como dominios personalizados o volúmenes persistentes. En una máquina virtual de Hetzner (por ejemplo, un CX22 con 4 GB de RAM), despliegas el mismo `docker-compose.yml` entero dentro de un solo servidor, pagando una tarifa plana mensual. Toda la red interna entre contenedores es local y de alta velocidad, sin costes de transferencia interna.

Otro aspecto clave es la arquitectura de red. Hetzner ofrece una red privada (vSwitch) que permite que varios servidores se comuniquen entre sí a través de una IP privada sin pasar por Internet. Esto es crucial para proyectos Docker en modo *swarm* o para conectar un servidor de aplicación con un servidor de base de datos sin exponer puertos sensibles. Además, incluyen protección contra ataques DDoS a nivel de red, algo que a menudo es un complemento de pago en otros proveedores.

También es relevante entender su oferta de servicios gestionados auxiliares. Tienen un sistema de almacenamiento de objetos (Hetzner Storage Box) que se puede montar como volumen en tu contenedor, y un registro de contenedores privado (Hetzner Harbor) para almacenar tus imágenes Docker sin los límites de Docker Hub. Esto permite construir un flujo de integración continua (CI/CD) completo sin depender de terceros externos, manteniendo todo el ecosistema dentro de un mismo proveedor de facturación y con baja latencia de red.

Sin embargo, hay un matiz que a menudo se omite: su nube no es "elástica" en el sentido de autoescalado mágico a nivel de clúster. Puedes escalar verticalmente (más RAM/CPU en el panel), pero el escalado horizontal de tus contenedores dependerá de tu propia automatización (por ejemplo, usando Terraform para crear más nodos trabajadores). Hetzner proporciona la API para hacerlo, pero no tienes un botón de "escalar" como en servicios más caros.

En definitiva, Hetzner para Docker es la elección del artesano digital. Es la plataforma para el desarrollador que no teme escribir un par de comandos SSH y que valora el rendimiento bruto por euro invertido. Es la diferencia entre alquilar un piso amueblado con servicios de conserjería (PaaS) y comprar un loft diáfano con altísimos techos donde tú decides dónde van las paredes (IaaS con Hetzner). Para proyectos personales, startups con presupuesto ajustado o aplicaciones en producción donde la latencia y el coste importan, es una solución formidable.

Aspectos importantes a evaluar

Aspectos importantes a evaluar antes de migrar a Hetzner

Tomar la decisión de mover tu infraestructura Docker a Hetzner implica evaluar factores que van más allá del precio por hora o del tráfico incluido. La experiencia real con este proveedor depende de cómo se alinean sus características con tu caso de uso concreto. Analicemos los puntos críticos que marcarán la diferencia entre un despliegue fluido y una serie de dolores de cabeza innecesarios.

El factor de la reputación y el soporte

Hetzner no es un gigante como AWS o Google Cloud, pero su reputación en la comunidad de desarrolladores y administradores de sistemas es notablemente sólida. Fundada en 1997 en Alemania, la compañía ha construido su nombre sobre una base de usuarios técnicos que valoran la relación calidad-precio y la fiabilidad. Sin embargo, debes entender qué implica esto en la práctica.

El soporte de Hetzner es funcional pero no es el tipo de asistencia que te va a acompañar durante la configuración de tu stack. La comunicación se realiza principalmente a través de un sistema de tickets, y los tiempos de respuesta pueden variar desde unos minutos hasta varias horas dependiendo de la carga. Las respuestas son directas, técnicas y a veces escuetas; no esperes un trato excesivamente ceremonioso. Si tu proyecto depende de un SLA estricto con atención telefónica inmediata, tendrás que ajustar tus expectativas. Si por el contrario eres una persona que prefiere resolver problemas consultando documentación y foros técnicos, este enfoque te resultará natural y eficiente.

La documentación oficial es extensa y cubre la mayoría de los escenarios, incluyendo guías específicas para configurar Docker y diversas herramientas de orquestación. El foro de la comunidad es otro recurso valioso: los usuarios experimentados responden con rapidez y los empleados de Hetzner también participan directamente, lo que añade una capa de confianza a las soluciones propuestas.

Evaluación precisa de los costes

El precio de un Cloud Server en Hetzner empieza en unos 3,79 € al mes para el modelo CX22, que incluye un AMD EPYC, 2 vCPU, 4 GB de RAM y 40 GB de disco NVMe. Esta tarifa es atractiva, pero el coste total de propiedad requiere un análisis más detallado.

El tráfico incluido es un punto destacable: obtienes 20 TB de transferencia mensual en IPv4 e IPv6 ilimitada. Para un proyecto Docker que maneja APIs internas o sitios web con tráfico moderado, esta cifra es prácticamente un margen de maniobra enorme. En la práctica, el tráfico de salida solo se cobra si superas los 20 TB o una velocidad media de 1 Gbps, lo cual es poco habitual en la mayoría de los despliegues.

Donde debes prestar especial atención es en la facturación de las IPs. Hetzner cobra 0,50 € al mes por cada IPv4 adicional o principal. Puede parecer un detalle menor, pero si tu arquitectura Docker requiere múltiples contenedores que necesitan puertos IP dedicados o si gestionas varios servicios con certificados SSL, este coste se acumula. Una alternativa que debes considerar seriamente es apoyarte en IPv6 para los servicios de solo salida o usar un reverse proxy como Traefik o Nginx para concentrar el tráfico y evitar la necesidad de múltiples IPv4.

Otro aspecto que suele olvidarse es el almacenamiento adicional. La arquitectura de Docker con volúmenes puede llenar un disco de 40 GB con imágenes, capas y datos de bases de datos en pocas semanas si no monitorizas el uso. Los volúmenes adicionales en Hetzner se facturan por separado y requieren que elabores un esquema de backup realista. Podrías pagar al final del mes mucho más de lo que esperabas si no planificas el crecimiento de datos.

Rendimiento heterogéneo y tipos de instancias

No todos los Cloud Servers de Hetzner son iguales. La gama CX (básica) utiliza CPUs AMD EPYC de generaciones variadas, mientras que la serie CPX usa procesadores más recientes, y los dedicados CCX ofrecen núcleos completos garantizados. La elección condiciona tu experiencia con Docker de forma determinante.

Si tu proyecto requiere compilaciones de imágenes Docker frecuentes o servicios que hagan un uso intensivo de CPU, como procesamiento de datos o renderizado, deberías optar por las instancias CPX o incluso por servidores dedicados. El compartir CPU en las instancias CX se traduce en una variabilidad de rendimiento notable, especialmente en momentos de alta demanda en el host subyacente. Notarás tiempos de compilación que fluctúan, y esto afecta a tus pipelines de integración continua.

Hetzner ofrece opciones de arquitectura en la nube con HA (alta disponibilidad), pero debes saber que no hay un servicio gestionado de orquestación de contenedores como EKS o GKE. Si tu objetivo es gestionar un cluster Docker Swarm o Kubernetes, tendrás que construir sobre las instancias cloud y gestionar tú mismo la resiliencia, el almacenamiento distribuido y el equilibrio de carga. Esto añade una capa de complejidad que no es inherente al proveedor, sino a la elección de una plataforma no gestionada.

En términos de red, la latencia entre los centros de datos de Hetzner en Frakfurt y Helsinki es excelente para Europa, pero si tu base de usuarios está en Norteamérica o Asia, la experiencia será mediocre en comparación con un proveedor con presencia multi-región. Hetzner tiene presencia también en Singapur y Estados Unidos desde hace unos años, pero el catálogo de servicios disponible allí es más limitado y el rendimiento de red puede variar.

Almacenamiento y persistencia de datos con Docker

La gestión de volúmenes persistentes es uno de los puntos que más quebraderos de cabeza genera a quien migra de soluciones como un VPS tradicional o una infraestructura on-premise. Hetzner ofrece volúmenes de bloque adicionales, pero no tienen la capacidad de autoescalado ni las snapshots transaccionales que obtienes con servicios cloud más enfocados a contenedores.

Los discos NVMe locales de los Cloud Servers son rápidos y fiables, pero al usar Docker, las capas de imágenes y los volúmenes bind mount ocupan espacio rápidamente. El backup automático que ofrece Hetzner por un coste adicional crea snapshots del servidor completo, lo que es útil para recuperaciones completas, pero no es un sustituto de una estrategia de backup a nivel de aplicación. Para un stack Docker con una base de datos PostgreSQL o MySQL, el snapshot a nivel de servidor puede resultar en inconsistencias si no haces un dump previo de las bases de datos.

Una práctica recomendada es externalizar los datos persistentes a un volumen de bloque separado y montarlo en el host, o incluso usar un sistema de archivos distribuido si tu proyecto alcanza envergadura. En este sentido, Hetzner también ofrece servicios de storage como Object Storage S3, pero la latencia y la ausencia de un sistema de mount nativo hacen que no sea ideal para datos activos.

Permisos y control administrativo

La consola web de Hetzner es funcional y te da acceso a la gestión de instancias, redes privadas, firewalls y DNS. La API es completa y documentada, lo que permite la integración con herramientas de automatización como Terraform, Ansible o incluso scripts personalizados. Para los entusiastas de Docker que buscan reproducir su entorno de manera programática, esto es un gran valor.

Sin embargo, la gestión de usuarios y permisos a nivel de IAM no es tan granular como la de grandes nubes. No existen roles complejos ni políticas de acceso detalladas para cada recurso. Para un proyecto personal o una startup pequeña, esto es más que suficiente. Para una empresa con cumplimiento normativo estricto, puede ser un obstáculo.

La red privada (VPC) es un recurso que debes configurar desde el inicio. Facilita la comunicación entre contenedores en distintos hosts sin exponer puertos a Internet. No cometas el error de abrir todos los puertos en el firewall y depender exclusivamente de la autorización por token; las buenas prácticas de seguridad Docker pasan por aislar los servicios internos, y la red privada de Hetzner junto con los grupos de seguridad pueden conseguirlo.

En conclusión, evaluar Hetzner para tu proyecto Docker es sopesar un servicio cloud sólido y transparente en costes con una ausencia de servicios gestionados avanzados y un soporte más orientado al autoservicio. Si tu equipo tiene capacidad técnica para configurar, monitorizar y escalar su propia infraestructura, la relación calidad-precio es difícil de superar. Si por el contrario tu prioridad es minimizar tareas operativas y externalizar el mantenimiento, deberás considerar si la diferencia de precio justifica migrar a una plataforma más gestionada. La decisión final depende de tu capacidad para asumir el control operativo y de tu tolerancia a resolver tus propios problemas con la documentación y la comunidad como compañía.

Cómo funciona o cómo tomar una decisión

Cómo decidir si Hetzner es la plataforma adecuada para tus proyectos con Docker

Tomar la decisión de mover tus contenedores a Hetzner no debería basarse únicamente en el precio, aunque sea un factor muy atractivo. El proceso real exige evaluar tres ejes principales: la naturaleza de tu proyecto, tu capacidad para gestionar la infraestructura y el modelo de facturación que mejor se adapta a tu flujo de trabajo. Aquí es donde muchos tutoriales fallan: no te explican el *porqué* detrás del *cómo*. Vamos a desglosarlo.

El primer filtro: ¿Qué tipo de proyecto estás desplegando?

Hetzner ofrece dos rutas principales para Docker: Cloud (máquinas virtuales clásicas) y Robot (servidores dedicados). La elección no es arbitraria, depende del perfil de carga de tu proyecto.

El segundo filtro: Tu nivel de comodidad con la operación

Hetzner es una plataforma *bare metal* o de nube "cruda" en el mejor sentido. No encontrarás un servicio gestionado de Kubernetes (EKS o GKE) listo para usar con un botón. Esto significa que el proceso de decisión debe incluir una autoevaluación honesta.

El caso práctico de la seguridad: En AWS, puedes lanzar una instancia y olvidarte del firewall de red porque el Security Group actúa como capa externa. En Hetzner, el firewall de Cloud está disponible pero desactivado por defecto en muchas imágenes. Si no configuras `iptables` o el firewall de Hetzner, tus puertos de Docker (como el 2375 o el 5432) quedarán expuestos a Internet en menos de 5 minutos. Esto no es un defecto, es una característica de control. Un usuario experto valora esto; un principiante puede sufrir un ataque de minado de criptomonedas al día siguiente de desplegar su contenedor.

El factor "Docker Compose vs. Swarm": Para la mayoría de los proyectos, tomar la decisión de usar Hetzner implica asumir que orquestarás con Docker Swarm o Compose. No necesitas Kubernetes a menos que tengas decenas de microservicios. Si tu proyecto es monolítico o tiene 3-4 servicios, un solo servidor Hetzner con Docker Compose es arquitectónicamente superior y más barato que un clúster de tres máquinas en cualquier otro proveedor. El proceso de decisión aquí es: *"¿Puedo justificar el costo operativo de un orquestador para mi escala?"*. Si la respuesta es no, Hetzner se convierte en tu mejor aliado.

El tercer filtro: Volumes y persistencia de datos

Un error común al migrar a Hetzner es tratar los contenedores como entidades efímeras sin planificar el almacenamiento. Hetzner ofrece Volumes (almacenamiento en bloque) que puedes montar en tus contenedores vía NFS o ext4.

El proceso de decisión debe incluir esta pregunta: ¿Tu base de datos debe sobrevivir a la eliminación del contenedor?

Hetzner cobra los Volumes por GB, y aunque son más caros que el disco local, ofrecen redundancia. No tomes la decisión de usar el disco local por ahorrar 3 euros al mes si tu proyecto maneja datos de usuarios reales. La utilidad práctica del Volume es que te permite usar la API de Hetzner para hacer *snapshots* del volumen sin detener el contenedor, algo que no todos los proveedores low-cost ofrecen.

El proceso de prueba recomendado

Para evitar el error de elegir el plan equivocado, te sugiero este flujo práctico:

  1. Crea una instancia `CX22` (la más barata) y despliega tu `docker-compose.yml` completo.
  2. Mide la memoria real: No te fíes de la RAM teórica. Ejecuta `docker stats` durante 24 horas con tráfico simulado. Si el uso de memoria supera el 80% de la instancia, escala a `CX32` (4 vCPU, 8 GB). El precio sube, pero la regla de oro es: *el cuello de botella debe estar en la red, nunca en la RAM*.
  3. Monitorea el I/O de red: Si tu proyecto usa WebSockets o streaming, presta atención al límite de ancho de banda. Hetzner ofrece 20 TB de tráfico por mes en la mayoría de los planes, pero si tu backend de Docker se comunica constantemente con un frontend externo, esos GB se agotan rápido.

Decisión final: ¿Migrar todo o solo una parte?

No tienes que tomar una decisión binaria. Un enfoque pragmático es usar Hetzner exclusivamente para servicios auxiliares de Docker que son intensivos en cómputo pero no críticos (como workers de cola o generación de PDFs) mientras mantienes el frontend principal en otro proveedor con mejor CDN global. Hetzner está en Europa (Falkenstein, Núremberg y Helsinki), así que si tu audiencia está en América, necesitarás añadir una capa de caché. Si tu audiencia es europea o no depende de baja latencia para la API, la decisión de centralizar todo en Hetzner es técnicamente sólida y financieramente óptima.

Evalúa estos tres puntos y tendrás una hoja de ruta clara para decidir si la plataforma envuelve tus necesidades o si solo estás seducido por el precio.

Ventajas y limitaciones

Ventajas de usar Hetzner con Docker: potencia real a precio competitivo

Cuando se habla de desplegar contenedores en producción, la conversación suele girar en torno a los grandes proveedores de nube pública. Pero existe una alternativa que ha ganado una reputación sólida entre desarrolladores y startups por una razón muy concreta: ofrece una relación precio-rendimiento difícil de igualar. Hetzner, un proveedor alemán con más de dos décadas de historia, se ha convertido en un destino natural para quienes quieren ejecutar Docker sin pagar la prima de los hyperscalers.

Rendimiento bruto por euro invertido

La primera ventaja que cualquier usuario nota al trabajar con Hetzner es el equilibrio entre recursos y coste. Un servidor dedicado o un VPS (Cloud Server) de gama media ofrece especificaciones que, en otros proveedores, podrían duplicar o triplicar la factura mensual.

Pongamos un ejemplo práctico. Un CX42 de Hetzner Cloud incluye 8 vCPU dedicadas (AMD EPYC), 16 GB de RAM y 160 GB de NVMe por aproximadamente 15-20 euros al mes. Con esa configuración, puedes ejecutar una pila completa de Docker Compose con varios servicios: una API backend, una base de datos PostgreSQL, Redis para caché y un proxy Nginx. Ese mismo rendimiento en AWS o GCP, con instancias tipo m5.large o similar, implicaría un coste mensual significativamente mayor, y eso sin contar el tráfico de salida.

Además, el ancho de banda incluido es otro punto fuerte. Hetzner ofrece hasta 20 TB de tráfico de salida en muchos de sus planes, y la conexión a internet es rápida y estable desde los centros de datos europeos (y también desde sus ubicaciones en EE. UU.). Para proyectos que mueven imágenes de contenedores, logs o datos de usuario, esta generosidad en el tráfico evita sustos en la factura.

Simplicidad operativa con Docker Compose

A diferencia de las soluciones gestionadas de orquestación como Kubernetes en la nube, Hetzner no te obliga a usar su propio ecosistema. Puedes optar por un enfoque pragmático: un servidor con Docker instalado y gestionar todo con Docker Compose. Esta simplicidad es una ventaja en sí misma, porque reduce la curva de aprendizaje y la complejidad operativa.

Para un equipo pequeño o un proyecto en fase de crecimiento, levantar la infraestructura es casi inmediato: creas un servidor, instalas Docker, clonas tu repositorio y ejecutas `docker compose up -d`. No hay que lidiar con VPCs complejas, IAM policies o redes privadas virtuales con configuraciones laberínticas. Hetzner te da un servidor con IP pública directa y, a partir de ahí, el control es tuyo.

Esto no significa que carezca de herramientas de gestión. Hetzner Cloud incluye firewalls integrados, volúmenes de almacenamiento adicionales, snapshots y backups automáticos. Puedes aplicar todo esto a tus contenedores sin necesidad de añadir capas extra de software. Por ejemplo, puedes programar un backup semanal del volumen donde Docker persiste los datos de tu base de datos, y restaurarlo con un par de clics.

Flexibilidad para redes y almacenamiento persistentes

Docker en producción exige resolver dos problemas: la persistencia de datos y las redes entre servicios. Hetzner ofrece soluciones directas para ambos casos.

Para la persistencia, tienes volúmenes de bloque que puedes montar en tus contenedores. Funcionan de manera análoga a un EBS de AWS: los conectas a tu servidor, los formateas y los usas para almacenar datos de bases de datos, archivos subidos por usuarios o cualquier otro dato que deba sobrevivir al ciclo de vida del contenedor. La ventaja es que no necesitas instalar un plugin especial ni configurar un cliente de almacenamiento en la nube dentro del contenedor; simplemente montas el volumen en el host y lo enlazas con un bind mount.

En cuanto a redes, Hetzner Cloud cuenta con redes privadas (vSwitch) que te permiten aislar el tráfico entre tus servidores. Si tu proyecto crece y decides separar servicios en máquinas distintas, puedes crear una red privada donde los contenedores se comuniquen sin exponer puertos a internet. Esto es un paso intermedio útil antes de saltar a un orquestador completo.

Hetzner también ofrece la posibilidad de usar sus servidores dedicados (dedicated servers) si tu carga de trabajo es intensiva, por ejemplo, para hacer self-hosting de servicios como GitLab, o para ejecutar pipelines de CI/CD con muchos workers. Puedes incluso combinar servidores dedicados con cloud servers dentro de la misma red privada, lo que te da una arquitectura híbrida sin atarte a un único tipo de infraestructura.

Control total sin bloqueo de proveedor

Otra ventaja que valoran los equipos técnicos es la ausencia de lock-in. Al usar Docker y Docker Compose, tu configuración es portable. Si mañana decides mudarte a otro proveedor o a tu propio hardware, te llevas los archivos `docker-compose.yml` y los volúmenes de datos. No dependes de servicios propietarios de Hetzner para que tu aplicación funcione.

Este nivel de control también se nota en el acceso directo a los recursos. Tienes acceso root al servidor, puedes ajustar parámetros del kernel, configurar redes personalizadas de Docker, usar Traefik o Caddy como reverse proxy, o instalar cualquier herramienta de monitoreo que prefieras. No estás limitado por una capa de abstracción gestionada que decida por ti cómo ejecutar tus contenedores.

Aspectos que debes considerar

A pesar de estas ventajas, es justo mencionar algunos matices. Hetzner, aunque ofrece alta disponibilidad en sus centros de datos, no es una nube con múltiples zonas de disponibilidad interconectadas de la misma manera que los hyperscalers. Si tu arquitectura exige tolerancia a fallos a nivel de zona con conmutación automática, tendrás que diseñarla tú mismo con herramientas como Keepalived, load balancers propios o replicación manual entre servidores.

También hay que considerar que el soporte técnico, aunque competente, no tiene el mismo tiempo de respuesta que los grandes proveedores si tienes un contrato empresarial. La documentación es buena, pero te beneficiará tener cierta autonomía para resolver problemas de configuración por tu cuenta.

Para la mayoría de los proyectos con Docker —una API, un sitio web con tráfico considerable, un SaaS en fase inicial, un servidor de aplicaciones internas—, Hetzner ofrece un punto dulce donde el rendimiento, el precio y la simplicidad se combinan de forma excelente. La clave está en entender qué tipo de cargas obtenéis y aprovechar la flexibilidad que proporciona Docker para adaptar el entorno a vuestras necesidades reales.

Errores comunes

Errores comunes: decisiones que convierten un buen despliegue en un dolor de cabeza

Trabajar con Hetzner y Docker es una combinación potente, pero precisamente por esa flexibilidad es fácil caer en trampas que, a la larga, cuestan tiempo y dinero. La mayoría de los problemas no vienen de la plataforma en sí, sino de cómo se configuran los servicios. Veamos los fallos más habituales y, lo más importante, cómo sortearlos.

El error del "todo en la red por defecto"

Es el clásico: levantas un `docker-compose.yml` con la base de datos, el backend y el frontend, y todos quedan colgados de la red `bridge` por defecto. Al principio funciona, pero es una bomba de relojería.

Cómo evitarlo: Define redes personalizadas en tu archivo de compose. No expongas puertos de servicios internos (como PostgreSQL o Redis) al host, y mucho menos a Internet. Comunica los contenedores entre sí por el nombre del servicio dentro de la red definida, no por `localhost` ni por IPs. Si el frontend necesita hablar con el backend, que lo haga a través de `http://backend:8000`, no a través de una IP flotante. Esto aísla fallos y mejora la seguridad de forma drástica.

Ignorar el firewall del proveedor (y el del sistema)

Hetzner ofrece un firewall integrado en su consola. Muchos lo desactivan porque "ya tienen `ufw`". El problema es que `ufw` dentro del contenedor o incluso en el host puede confundirse con las reglas de NAT que Docker crea. Es frustrante abrir el puerto 8080 en `ufw` y que el contenedor siga inaccesible porque las cadenas de Docker se saltan esas reglas.

Cómo evitarlo: Usa el firewall de Hetzner como tu primera línea de defensa. Es gratis, se aplica antes de que el tráfico llegue a tu servidor y es extremadamente fácil de gestionar. Permite solo los puertos necesarios (80, 443, 22 para SSH y, si acaso, algún puerto de administración con IP de origen restringida). En el host, deja `ufw` desactivado o configúralo sabiendo que Docker manipula `iptables` directamente. La combinación de ambos suele ser la causa de dolores de cabeza.

Contenedores que mueren con el server

Levantas un contenedor con `docker run -d` o con `docker compose up -d` y das por hecho que estará ahí para siempre. Si el servidor se reinicia (por un update del kernel, un fallo de red o un reboot manual), tus servicios se quedan caídos. Es el error más común de todos.

Cómo evitarlo: Crea un servicio `systemd` para tu stack de Docker o, mejor aún, usa las opciones de reinicio de Docker Compose. Define `restart: unless-stopped` en cada servicio de tu archivo `docker-compose.yml`. Esto asegura que, si el daemon de Docker arranca, tus contenedores también lo harán. Para stacks complejos, considera usar `systemd` para gestionar el arranque de servicios dependientes, pero para la mayoría de los casos, la directiva `restart` es más que suficiente.

La mala praxis de las imágenes "latest"

El espejismo de usar `nginx:latest` o `postgres:latest` para "estar al día" es una receta para el desastre. Un cambio de versión mayor puede romper tu aplicación sin previo aviso. Un `docker pull` en el próximo deploy actualizará, por ejemplo, PHP de la 8.2 a la 8.3 y tu código legacy dejará de funcionar.

Cómo evitarlo: Fija las versiones de las imágenes en tu compose. Usa etiquetas específicas como `postgres:16.2-alpine` o `node:20.11-slim`. Cuando quieras actualizar, cambia la etiqueta conscientemente, prueba en un entorno de staging y luego despliega. Esto convierte un despliegue arriesgado e imprevisible en un proceso controlado y reversible.

El volumen de datos atado a la vida del contenedor

Si defines un volumen sin nombre en tu `docker-compose.yml` (o lo montas directamente en el filesystem del contenedor), estás firmando la sentencia de muerte de tus datos. Si borras el contenedor con `docker-compose down`, los datos de tu base de datos desaparecen con él.

Cómo evitarlo: Utiliza volúmenes nombrados de Docker. Define algo como `db_data:/var/lib/postgresql/data` en tu archivo de compose. Docker gestionará la persistencia en el host sin que tengas que preocuparte por rutas frágiles. De esta forma, puedes hacer `docker-compose down` y `up` sin perder nada. Para backups más robustos, considera montar un volumen que apunte a un directorio específico del host (`/var/lib/docker/volumes` a veces es incómodo), pero siempre con la intención explícita de que ahí vive la base de datos.

No monitorizar ni los recursos ni el tráfico

Hetzner te da un panel, pero mirarlo una vez a la semana no es monitorización. Un contenedor puede estar comiendo CPU o RAM sin que te des cuenta hasta que el server se congela. O peor: una ruta de tu API puede estar siendo atacada con tráfico no deseado que consume tu ancho de banda.

Cómo evitarlo: Configura herramientas de monitorización desde el día uno. `docker stats` es una solución rápida y manual, pero no es suficiente. Instala un agente como Prometheus con Grafana, o un servicio más simple como Netdata (muy fácil de levantar con Docker). Estas herramientas te darán alertas proactivas. También puedes usar la métrica de tráfico del panel de Hetzner para detectar picos anómalos y, con el firewall integrado, bloquear IPs agresivas de forma preventiva.

Asumir que el proveedor gestiona tu backup

Hetzner ofrece snapshots, pero crear uno cada mes no es una estrategia de backup. Cómo evitarlo: Automatiza los backups de tu base de datos y de los volúmenes críticos fuera del servidor. Un script con `cron` que haga un `pg_dump` de tu base de datos y lo suba a un bucket de Hetzner Object Storage (o a otro proveedor) es imprescindible. El snapshot de Hetzner es para recuperar el sistema entero ante un fallo de hardware, no para recuperar un registro borrado por error ayer.

Evitar estos errores no solo te ahorrará un susto a las 3 de la mañana, sino que hará que tu arquitectura con Docker en Hetzner sea profesional, predecible y fácil de mantener.

Preguntas frecuentes

¿Qué tan fácil es usar Docker en Hetzner?

Hetzner no ofrece un servicio de Docker gestionado como "Docker Swarm como servicio" o similar. Esto, lejos de ser una desventaja, es parte de su filosofía: tú tienes el control total del servidor. La integración es total porque cualquier Cloud Server o dedicado de Hetzner es un servidor Linux estándar (Ubuntu, Debian, Fedora, etc.) sobre el que instalas Docker Engine o Docker Compose sin ninguna restricción.

El proceso es idéntico al que seguirías en un VPS de cualquier otro proveedor: conectarte por SSH e instalar los paquetes oficiales. La verdadera facilidad aparece cuando usas herramientas como `docker context` o `docker-machine`. Puedes definir un contexto de Docker en tu máquina local que apunte a tu servidor de Hetzner, de modo que los comandos `docker build` o `docker compose up` se ejecuten directamente en la máquina remota, sin necesidad de configurar pipelines complejos. Para proyectos pequeños o en fase de prototipo, esta es la forma más rápida de desplegar, incluso más que usar una plataforma como Heroku, porque no tienes límites de memoria o usos específicos del plan.

¿Hay límites de ancho de banda o tráfico?

Un punto a favor de Hetzner es que el tráfico de red dentro de su red interna (`eth1`) es gratuito e ilimitado. Para el tráfico público (hacia internet), la política ha cambiado con los años. En la mayoría de los planes actuales (Cloud y dedicados), el tráfico público de salida es ilimitado, pero con un costo adicional si superas una cierta cantidad de TB (generalmente 20 TB para servidores Cloud estándar). El tráfico de entrada es gratuito.

Esto tiene implicaciones prácticas para Docker: si tu aplicación genera mucho tráfico saliente (por ejemplo, sirviendo imágenes o archivos grandes), prepárate para pagar un extra, aunque el precio por TB es bastante bajo. Para proyectos cuya carga principal es la comunicación entre contenedores (como un frontend que llama a una API interna), el tráfico entre ellos es interno y libre. No hay sorpresas en este aspecto, y su política de tráfico es de las más transparentes del mercado.

¿Qué pasa si necesito escalar mi aplicación Docker?

Hetzner no tiene balanceadores de carga gestionados tan avanzados como los de AWS o GCP, aunque sí ofrecen un Load Balancer básico y funcional. Para escalar, tienes dos caminos reales. El primero es usar un Cloud Server más grande (escalado vertical): apagar el servidor, cambiar el plan en el panel y reiniciar. Es rápido y no pierdes datos. El segundo es el escalado horizontal: crear varios nodos Docker y usar Docker Swarm o Kubernetes (k3s) que se comunican a través de la red privada de Hetzner.

La clave aquí es que Hetzner no te vende "clústeres" con un clic. Tú eres responsable de instalar y mantener la capa de orquestación. Sin embargo, existen herramientas como `k3s` que se instalan en minutos. Para la mayoría de los proyectos que usan Docker Compose, el escalado vertical suele ser más que suficiente, y el precio del escalado vertical en Hetzner es muy competitivo comparado con otros proveedores. Si necesitas auto-scaling dinámico, tendrás que implementarlo tú mismo (con scripts o apps como el proyecto `docker-autoscale`, aunque esto añade complejidad.

¿El soporte de Hetzner sirve de ayuda si tengo problemas con mis contenedores?

Hetzner tiene soporte técnico, pero debes tener expectativas claras: su equipo administra la infraestructura física y la red, no tus contenedores. Si tienes un problema con una imagen Docker, un error de configuración en Compose o un crash de tu aplicación, el soporte no te lo va a resolver. Sin embargo, son muy eficientes y rápidos si tu problema es de hardware, IP, red o kernel.

En proyectos Docker, los problemas más comunes (puertos ocupados, volúmenes corruptos, falta de memoria) son de tu responsabilidad. Lo que sí apreciarás es su velocidad de respuesta (suele ser en menos de 2 horas) para temas de infraestructura. No esperes un "chat en vivo" para configurar tu `nginx.conf`; busca eso en la comunidad (foro de Hetzner) o en Stack Overflow. Como consejo útil: revisa el panel de control y los gráficos de monitorización; mágicamente, muchos problemas de contenedores son problemas de recursos (memoria o I/O), y Hetzner te da los datos de forma clara.

¿Hetzner es adecuado para proyectos Docker en producción?

Absolutamente, siempre que entiendas qué estás comprando. Es la opción ideal para proyectos de tamaño medio o productos SaaS que necesitan potencia bruta a buen precio. Para producción, la combinación perfecta suele ser un Cloud Server con volúmenes extra para datos persistentes (porque no debes guardar datos de base de datos dentro del contenedor) y snapshots diarios. El panel de control te permite hacer snapshots del servidor completo (que incluye todas las imágenes Docker descargadas) de forma manual o programada, lo que facilita la recuperación ante desastres.

Lo que no encontrarás aquí son servicios gestionados integrados como "bases de datos como servicio" (tendrías que montar Postgres o MySQL tú mismo en un contenedor con un volumen). Generalmente, los usuarios que lamentan usar Hetzner en producción son aquellos que vienen de plataformas PaaS y no quieren lidiar con el mantenimiento del sistema operativo. Si te sientes cómodo administrando un servidor Linux y tienes una buena rutina de backups (por ejemplo, usando el objeto de almacenamiento S3 de Hetzner para volcar backups de tus volúmenes), la relación calidad-precio y el rendimiento son imbatibles en su rango de precios.

Conclusión

Hetzner no es solo un proveedor donde alquilar un VPS barato: es una plataforma que, combinada con Docker, te permite construir infraestructuras de producción con una relación precio-rendimiento difícil de igualar. A lo largo de este artículo hemos visto que la clave no está en la magia, sino en la configuración consciente: desde la elección del plan CX o CPX según la carga de trabajo, hasta la implementación de una red privada (VSwitch) para que tus contenedores no dependan de la IP pública para comunicarse entre sí.

Si te llevas algo de aquí, que sea esto: la simplicidad operativa de Docker no elimina la responsabilidad de la gestión del servidor. La virtualización de Hetzner es transparente y fiable, pero el rendimiento de tu stack dependerá de cómo limites los recursos con `docker-compose` (memoria, CPU) y de si adoptas volúmenes persistentes correctamente mapeados. Para proyectos personales o MVPs, un CX22 será suficiente. Para entornos con tráfico constante, el salto a un CPX31 con más RAM y disco NVMe marcará una diferencia notable sin disparar la factura. La decisión final es tuya, pero el criterio es claro: aprovecha la escalabilidad vertical que ofrece Hetzner, comienza pequeño con Docker y escala cuando tus métricas lo justifiquen.