Los servidores en la nube de hetzner proporcionan mucho rendimiento por euro, ofrecen opciones de vCPU dedicadas y compartidas, rápidas unidades SSD NVMe y facturación por minutos para un control total [1][2][5]. Te mostraré qué tarifas son adecuadas para sitios web, bases de datos y contenedores y cómo puedes empezar sin rodeos - incluyendo Precios y Consejos prácticos.
Puntos centrales
Los siguientes puntos le darán una breve orientación - luego entraré en detalle y le mostraré claramente Procesos de toma de decisiones y Ejemplos:
- Relación calidad-precioDesde 3,79 euros con NVMe y 20 TB de tráfico [5].
- EscalavCPU, RAM, almacenamiento sobre la marcha a través de API/CLI [3][4]
- SeguridadCortafuegos, protección DDoS, copias de seguridad, instantáneas [1][2]
- RedRedes privadas, IP flotantes, equilibradores de carga [1][4][5]
- UbicacionesDE, FI, US, SG - compatible con el RGPD en la UE [1][3]
Hetzner Cloud Server explicado brevemente
Hetzner ofrece máquinas virtuales basadas en las últimas CPU AMD EPYC, Intel Xeon y Ampere Altra, combinadas con unidades SSD NVMe en RAID10 y una conexión de 10 Gbit/s, lo que garantiza una gran velocidad. Latencias y IOPS [1][2][4]. Puedo elegir entre vCPU compartidas para proyectos web típicos y vCPU dedicadas para cargas de trabajo que requieren mucha CPU, como inferencia, pipelines de construcción o bases de datos [3][4]. La instalación se realiza en cuestión de minutos, tras lo cual controlo todo a través del panel web, la API REST o la CLI, incluidos cortafuegos, redes y volúmenes [4][5]. Las ubicaciones en Alemania y Finlandia ayudan con la protección de datos, mientras que otras regiones (EE.UU., Singapur) amplían el alcance para usuarios globales [1][3]. La facturación por minutos es adecuada para pruebas, campañas a corto plazo y trabajos de CI/CD, que se inician y detienen automáticamente, sin un marco temporal fijo. Duración [5].
Resumen de precios y tarifas
Para empezar, el precio ronda los 3,79 euros al mes (CX11, 1 vCPU, 2 GB de RAM, 20 GB de NVMe, 20 TB de tráfico), ideal para staging, bots o sitios web poco potentes [5]. Los proyectos de tamaño medio, como WordPress con caché o una tienda, funcionan cómodamente con 4-8 vCPU y 8-16 GB de RAM; los costes mensuales típicos oscilan entre 12,90 y 31,90 euros (por ejemplo, CX31/CX41/CPX41) [5]. Si desea núcleos dedicados, opte por las tarifas CCX: Esto proporciona tiempo de CPU constante para bases de datos o backends de API y cuesta entre 25,90 y 103,90 euros al mes, dependiendo del paquete [2][5]. Todas las tarifas incluyen un generoso tráfico de al menos 20 TB; los paquetes grandes llegan hasta 60 TB, más que suficiente para muchos proyectos [2]. Gracias a la facturación por minutos, sólo pago por el uso real. Utilice y mantener limpios los presupuestos planificable [5].
| Tarifa | vCPU | RAM | SSD NVMe | Tráfico | Precio/mes |
|---|---|---|---|---|---|
| CX11 | 1 (compartido) | 2 GB | 20 GB | 20 TB | aprox. 3,79 |
| CPX41 | 8 (Compartido) | 16 GB | 160 GB | 20 TB | aprox. 31,90 |
| CCX33 | 8 (Dedicado) | 32 GB | 240 GB | 20-60 TB | aprox. 103,90 euros |
Los costes adicionales son limitados: las IP públicas están disponibles por un cargo adicional en función del paquete, y se incluyen funciones como cortafuegos, redes privadas y utilización de API [1][2][4]. Si quieres ampliar el almacenamiento de forma flexible, puedes reservar volúmenes de hasta 10 TB por volumen y utilizar almacenamiento de objetos compatible con S3 para copias de seguridad o soportes si es necesario [1][5]. Esto me permite empezar poco a poco, crecer rápidamente y proporcionar más capacidad a corto plazo durante los picos de carga, y volver a reducirla más adelante. Esta elasticidad reduce el riesgo de sobreaprovisionamiento y evita sobreaprovisionamientos costosos. Tiempos muertos. Para los picos de computación intensiva, la opción de una vCPU dedicada sigue siendo un Ancla de rendimiento [2][5].
Funciones que cuentan en la vida cotidiana
La combinación de NVMe, la moderna generación de CPU y el enlace ascendente de 10 Gbit/s ofrece despliegues rápidos, una rápida entrega de paquetes y un buen rendimiento para las copias de seguridad [1][2][4]. Configuro cortafuegos con seguimiento de estado directamente en el panel o a través de la API y separo los servicios internos mediante redes privadas, lo que mantiene las interfaces reducidas y los servicios claramente aislados [1][4]. Las IP flotantes facilitan el mantenimiento porque cambio la IP a una instancia sana en caso de incidente y reenvío el tráfico sin latencia DNS TTL [4][5]. Guardo copias de seguridad e instantáneas de forma controlada en el tiempo para permitir reversiones tras actualizaciones o versiones defectuosas [1][5]. Para el escalado horizontal, coloco un equilibrador de carga delante de varias instancias, lo que resulta ideal para las instancias sin estado. Microservicios y APIs [4][5].
Automatización y API
Automatizo el aprovisionamiento, la red, las reglas de cortafuegos y los volúmenes en los pipelines CI/CD a través de la API REST y la CLI [4][5]. Las configuraciones de Terraform o Ansible asignan despliegues repetibles y reducen los clics manuales a cero. Esto me permite mantener la coherencia entre los entornos de desarrollo, ensayo y producción, lo que hace que los procesos de lanzamiento sean predecibles. Esto acorta el tiempo de obtención de valor de las nuevas funciones y minimiza el riesgo de fallos debidos a desviaciones. Para los equipos, esto supone Normas y menos Error en el día a día.
Primeros pasos: de la reserva al lanzamiento
Selecciono la ubicación (por ejemplo, Núremberg o Helsinki) para adaptarla al grupo destinatario y a los requisitos de protección de datos, creo la instancia y almaceno las claves SSH. A continuación, instalo la configuración básica: Actualizaciones del sistema, cortafuegos, Fail2ban y sincronización horaria, y después Docker/Podman o la pila del servidor web. Para WordPress o tiendas, planifico el almacenamiento en caché (por ejemplo, caché FastCGI) y un volumen de base de datos independiente para facilitar la migración. Configuro copias de seguridad y snapshots desde el principio para tener un camino claro de vuelta en caso de problemas. Utilizo un equilibrador de carga y una segunda instancia para aumentar la disponibilidad y reducir el riesgo de errores. Riesgo en Mantenimiento.
¿Para quién merece la pena empezar?
Los sitios web y los blogs se benefician de puntos de entrada favorables, mientras que las tiendas y los portales con varias vCPU y 8-16 GB de RAM obtienen más aire [5]. Los desarrolladores utilizan el reloj por minutos para pruebas que sólo se ejecutan cuando es necesario, ahorrando así costes fijos [5]. Los clústeres de bases de datos, las pilas de contenedores o los sistemas de mensajería funcionan bien con vCPU dedicadas porque ofrecen un tiempo de CPU constante [2][4]. Las empresas centradas en la UE valoran las ubicaciones alemanas y finlandesas por su clara base de cumplimiento [1][3]. Si desea echar un vistazo más de cerca al ecosistema de hosting de Hetzner, puede encontrar una visión general compacta aquí. Visión general de Hetzner Webhosting con referencias útiles a escenarios de proyectos.
Hetzner Cloud frente a otros proveedores
El precio y el rendimiento destacan favorablemente en una comparación de mercado, especialmente debido a un hardware potente, mucho tráfico y una estructura de costes sencilla [2][5][6]. Para configuraciones de servidores dedicados, muchas comparaciones citan a webhoster.de como una clara recomendación en términos de rendimiento y soporte - esto es adecuado si el máximo control y los núcleos constantes son importantes [6]. Hetzner obtiene buenas puntuaciones en instancias en la nube con un funcionamiento sencillo, automatización y ubicaciones en la UE, que resultan útiles para los requisitos de protección de datos [1][3][4]. DigitalOcean y AWS Lightsail siguen siendo alternativas, especialmente si se requieren otros servicios del mismo ecosistema [6]. Para muchos proyectos web y de aplicaciones, Hetzner proporciona una sólida Base con moderada Costos [2][5].
| Proveedor | de precio | Tipo de CPU | Margen RAM | Tráfico | Ubicaciones | Valoración |
|---|---|---|---|---|---|---|
| webhoster.de | 3,89 € | EPYC/Xeon | 2-192 GB | 20-60 TB | DE, EU | ⭐⭐⭐⭐⭐ |
| Hetzner | 3,79 € | EPYC/Xeon/Altra | 2-192 GB | 20-60 TB | DE, EU, US, SG | ⭐⭐⭐⭐⭐ |
| DigitalOcean | 4,00 € | Compartido/Dedicado | 2-128 GB | 4-10 TB | UE, EE.UU. | ⭐⭐⭐⭐ |
| AWS Lightsail | 3,50 € | Compartido/Dedicado | 2-64 GB | 2-8 TB | En todo el mundo | ⭐⭐⭐⭐ |
Configuración optimizada para WordPress & Co.
Para WordPress, utilizo desde 2 vCPU y 4-8 GB RAM, activo OPcache, utilizo FastCGI cache o un plugin lean caching y separo las subidas multimedia en un volumen aparte. Una configuración NGINX/Apache con HTTP/2, Gzip/Brotli y la última versión de PHP garantiza tiempos de respuesta rápidos. Un equilibrador de carga con dos instancias ayuda con los picos, mientras que un servicio de base de datos externo o un volumen dedicado reduce los cuellos de botella de E/S. Para las tiendas, planifico entre 8 y 16 GB de RAM, reubico las sesiones y la caché y aseguro volcados regulares de la base de datos. De este modo, las instalaciones pueden soportar picos de carga y permanecer actualizadas receptivo y seguro.
Seguridad y protección de datos
Los cortafuegos de estado y la protección DDoS están en el panel, lo que me permite definir y reutilizar conjuntos de reglas por proyecto [1][2]. Las claves SSH, el inicio de sesión con contraseña desactivada y las actualizaciones periódicas son obligatorias, además de Fail2ban y la rotación de registros. Creo copias de seguridad controladas en el tiempo y las versiono; utilizo instantáneas antes de realizar cambios arriesgados para realizar reversiones rápidas [1][5]. En cuanto al cumplimiento de la normativa, elijo ubicaciones en la UE, separo los datos de los clientes en subredes y establezco funciones de mínimo privilegio en la API. Esto reduce las superficies de ataque y crea Procesos para Auditorías.
Administración, supervisión y apoyo
Superviso la CPU, la RAM, la E/S y la red con gráficos integrados o conecto Prometheus/Grafana para recopilar métricas de forma centralizada. Las alertas me ayudan a definir valores umbral para poder escalar u optimizar a tiempo. Para las configuraciones de servidores dedicados, merece la pena echar un vistazo a la herramienta Interfaz de robotsi los proyectos combinan ambos. El soporte está disponible 24 horas al día, 7 días a la semana, y las claras funciones de autoservicio me permiten resolver muchos problemas directamente en el panel [6]. Esto significa que los procesos operativos pueden planificarse y que puedo reaccionar más rápidamente a Incidentes y Picos.
Control de costes y escalado en la práctica
Empiezo con poco, etiqueto los recursos por proyecto/equipo y utilizo informes de costes mensuales para gestionar adecuadamente los presupuestos. El aumento y la reducción controlados en el tiempo reducen los costes fijos en los entornos de ensayo; el escalado automático con equilibradores de carga cubre las campañas o la estacionalidad. Si las cargas de trabajo requieren permanentemente mucho tiempo de CPU, cambio a una vCPU dedicada o considero la posibilidad de cambiar a un servidor físico. Para esta decisión, un breve Guía para servidores raízque facilita el pesaje de nubes y chapas. Esto me permite mantener los costes bajo control y mantener el rendimiento en el momento adecuado. Tiempo a la derecha Ubicación.
VCPU compartida frente a vCPU dedicada: la selección en la práctica
Las vCPU compartidas soportan los picos de carga de muchos clientes al mismo tiempo. Esto es eficiente y favorable siempre que las cargas de trabajo estén predominantemente ligadas a la E/S (servidores web, cachés, API con poco tiempo de CPU). Las primeras señales de que debería cambiar a vCPU dedicadas son una utilización constante de la CPU durante fases largas, colas de construcción que sólo se procesan lentamente o bases de datos con latencias notables para consultas complejas. Las vCPUs dedicadas ofrecen un tiempo de CPU predecible, evitan el tiempo de robo y suelen ser la mejor opción para cargas OLTP/OLAP, pipelines de inferencia o build runners CI. Práctico: puedo ampliar o reducir instancias mediante redimensionamiento, probar picos en CCX y volver a CPX cuando la carga disminuya. Para el control de costes, etiqueto estas ampliaciones y documento el motivo, de modo que los presupuestos puedan seguirse.
Estrategias de almacenamiento y rendimiento
El almacenamiento local NVMe de la instancia es muy rápido y es adecuado para el sistema operativo, las cachés y los artefactos transitorios. Utilizo volúmenes de bloques para los datos que necesitan vivir más tiempo y moverse entre instancias. Mejores prácticas: Separo los registros y los archivos de base de datos en sus propios montajes, activo noatimeDependiendo de la carga de trabajo, utilizo ext4 (sólido todoterreno) o XFS (bueno para archivos grandes) y planifico suficiente capacidad libre para ventanas de mantenimiento (por ejemplo, VACUUM/ALTER TABLE). Las instantáneas de los volúmenes se crean rápidamente, pero sólo son consistentes en caso de colapso; para sistemas exigentes, congelo el sistema de archivos brevemente o utilizo volcados lógicos. Hago versiones de las copias de seguridad, pruebo regularmente las restauraciones en una instancia de ensayo y externalizo grandes inventarios de medios al almacenamiento de objetos para mantener baja la E/S en los servidores de aplicaciones.
Diseño de redes, IPv6 y DNS
Las redes privadas separan las rutas de datos entre la aplicación, la base de datos y los servicios internos. Defino mis propias subredes para cada entorno (dev/stage/prod) y establezco políticas de cortafuegos restrictivas (denegación por defecto). IP flotantes Yo uso para despliegues azul-verde: Arrancar la nueva versión, esperar a las comprobaciones de estado y reasignar la IP, sin DNS TTL ni calentamiento de proxy. La pila dual con IPv4/IPv6 es el estándar; mantengo DNS inverso para emparejar los servicios de correo y API con el fin de mantener estables los tiempos de reputación y TLS handshake. Para el tráfico L7, el equilibrador de carga se encarga de las comprobaciones de estado, las sesiones fijas y la descarga TLS; internamente, dirijo los servicios a través de IP privadas para maximizar el ancho de banda y la seguridad.
Contenedores y Kubernetes en la nube de Hetzner
Para las cargas de trabajo de contenedores, empiezo con Docker Compose o Podman Quadlets en una instancia CPX: rápido, barato y rastreable. A medida que crece la configuración, aprovisiono un pequeño Kubernetes (kubeadm o k3s) con 3 nodos de plano de control/trabajador. El equilibrador de carga de la nube lo gestiona Ingress, mientras que el almacenamiento se proporciona como volúmenes dinámicos a través de un complemento de CSI. Separo los grupos de nodos según el tipo de carga de trabajo (por ejemplo, E/S pesada frente a CPU pesada) y mezclo CPX (rentable) con CCX (cálculo intensivo). El escalado se basa en eventos: los HPA/autoscalers garantizan la elasticidad a nivel de pods y nodos; yo escalo específicamente para campañas a través de la API y recapitalizo después. Es importante una ventana de actualización clara, en la que vacío nodos, muevo cargas de trabajo y mantengo la coherencia de las imágenes y los núcleos.
Alta disponibilidad y recuperación
La alta disponibilidad comienza con el desacoplamiento: estado en bases de datos/colas dedicadas, instancias de aplicaciones sin estado detrás de ellas. Distribuyo las instancias entre distintos hosts (colocación/esparcimiento), utilizo al menos dos servidores de aplicaciones detrás del equilibrador de carga y replico las instancias de base de datos de forma asíncrona. Regular Restablecer pruebas son indispensables: una copia de seguridad sólo se considera buena si puedo restaurarla limpiamente. Para el mantenimiento y los incidentes, defino objetivos RTO/RPO, tengo listos runbooks (por ejemplo, "DB failover", "rolling restart", "TLS rotation") y los practico en staging. Las estrategias multirregión reducen los riesgos relacionados con la ubicación; las estrategias DNS o anycast complementan las IP flotantes cuando se requiere un enrutamiento global.
Gobernanza, cumplimiento y gestión de accesos
Trabajo con proyectos y etiquetas para separar claramente los recursos y asignar los costes. Asigno fichas API según el principio de menor privilegio y los voy rotando regularmente. Utilizo roles de grupo para el acceso en equipo y bloqueo globalmente los inicios de sesión SSH con contraseña. Los secretos se almacenan en un gestor (por ejemplo, mediante ENV/Archivos sólo en RAM), no en Git. Archivo los registros de aprovisionamiento con fines de auditoría y mantengo una gestión de cambios concisa pero vinculante. Las ubicaciones en la UE ayudan con los requisitos GDPR; también aíslo los datos sensibles en subredes y cifro los volúmenes a nivel de SO.
Evitar las trampas de los costes: Consejos sobre el terreno
Las instancias desconectadas siguen costando mientras existan; sólo la eliminación pone fin a la facturación. Las instantáneas y las copias de seguridad tienen costes de almacenamiento aparte; yo limpio las generaciones antiguas automáticamente. Los equilibradores de carga, las IP flotantes y los volúmenes son baratos, pero se acumulan en grandes flotas: las etiquetas y los informes mensuales evitan los puntos ciegos. Los presupuestos de tráfico son generosos, pero sigo planificando las reservas y almacenando en caché los activos estáticos de forma agresiva. Para las cargas de trabajo en ráfaga, pongo en marcha instancias temporales durante un tiempo limitado y tengo preparada una lista de comprobación que se lleva consigo todos los recursos dependientes durante el desmantelamiento.
Migración y senda de crecimiento
Cambiar de vCPU compartida a dedicada es un paso habitual: clono la instancia mediante snapshot, arranco el nuevo tamaño, sincronizo los deltas y muevo la IP flotante. El tiempo de inactividad cero se consigue con Blue-Green o un equilibrador de carga: añado una nueva versión, muevo el tráfico paso a paso, controlo las fuentes de error y, a continuación, elimino el clúster antiguo. Planifico migraciones de bases de datos con replicación, cambio brevemente a sólo lectura y realizo la conmutación por error. En el camino hacia el hardware dedicado, mantengo los mismos patrones: separación clara de redes, rutas de automatización, copias de seguridad probadas y construcciones reproducibles, para que el paso siga siendo calculable.
Mi breve juicio
Los servidores en la nube de hetzner ofrecen una sólida relación calidad-precio, mucho tráfico y automatización sencilla: ideales para proyectos web, API y contenedores [2][4][5]. Si necesita una facturación flexible, ubicaciones en la UE y funciones predecibles, puede empezar rápidamente y seguir creciendo sin fricciones [1][3][4]. Los servidores dedicados, que webhoster.de menciona a menudo como recomendación en las comparativas [6], son ideales para cargas pesadas continuas o hardware especial. En la práctica, yo combino ambos: nube para la dinámica, dedicado para escenarios de núcleo constante. Esto mantiene la infraestructura ligera, la factura transparente y la Actuación Fiable recuperable.
