Self-Hosted vs Cloud: qué sale más barato en 2026
En 2026, la discusión de "nube contra servidores propios" ya no parece una batalla entre el pasado y el futuro. Se ha vuelto mucho más pragmática: las empresas vuelven a contar el dinero, miran las facturas reales y cada vez llegan más a la conclusión de que no existe una respuesta universal. Más aún, la propia tendencia se ha desplazado de cloud-first a cloud-appropriate: no "llevamos todo a la nube", sino "colocamos cada carga donde tenga sentido económica y técnicamente". En este giro han influido tanto el aumento de las facturas de las nubes públicas como los requisitos de data sovereignty y el deseo de contar con una infraestructura más predecible. De este cambio hablan tanto los medios del sector, citando encuestas recientes a CIO, como las propias empresas, que cuentan públicamente cómo salen de la nube. (TechRadar)
Por qué las empresas vuelven a self-hosted
La razón número uno no es la ideología, sino la factura de fin de mes. Mientras un proyecto es pequeño, la nube parece casi magia: pulsas un botón y obtienes una VM, una base de datos gestionada, un balanceador, object storage y un CDN. Pero cuando la infraestructura crece, resulta que la empresa no paga solo por CPU y RAM, sino también por tráfico de red, NAT Gateway, servicios gestionados, backups, IOPS, snapshots, IP públicas, tráfico entre zonas y decenas de pequeñas líneas en la facturación. En AWS, por ejemplo, solo NAT Gateway en una región típica cuesta $0.045 por hora más $0.045 por cada gigabyte procesado; el tráfico saliente a internet para EC2, una vez superados los 100 GB mensuales gratuitos, también se cobra por separado. (Amazon Web Services, Inc.)
La segunda razón es la previsibilidad. Con bare metal o un dedicated server alquilado, el precio suele ser más simple: un pago mensual fijo, especificaciones de hardware claras y un mínimo de sorpresas a final de mes. Precisamente por eso Hetzner y OVHcloud vuelven a aparecer a menudo en conversaciones sobre cost efficiency: siguen ofreciendo una relación fuerte entre precio y recursos, especialmente para cargas constantes y uniformes. Al mismo tiempo, conviene recordar que incluso Hetzner subió precios en 2026: el hardware barato sigue siendo barato frente a los hyperscalers, pero ya no es tan ridículamente barato como hace un par de años. (Hetzner)
La tercera razón es el control. Para algunas empresas, la cuestión ni siquiera está en el ahorro directo, sino en que self-hosted facilita cumplir con reglas internas de seguridad, requisitos de compliance, políticas de ubicación de datos y auditorías. OVHcloud, por ejemplo, pone énfasis explícito en certificaciones, private networking, anti-DDoS y espacio de backup gratuito dentro de su oferta de dedicated servers. (OVHcloud)
Y, por último, hay casos públicos demasiado sonados como para ignorarlos. 37signals afirma que su salida de la nube les ahorrará alrededor de 10 millones de dólares en cinco años y reducirá los gastos de infraestructura aproximadamente a la mitad o incluso a un tercio. Eso no significa que vaya a pasarle a todo el mundo. Solo significa una cosa: para cierta clase de sistemas maduros, predecibles y con carga constante, self-hosted ha vuelto a ser una opción financieramente seria y no una simple "nostalgia del cuarto de servidores". (Basecamp)
Dónde self-hosted es especialmente fuerte en 2026
Si hablamos del mercado práctico, en Europa suelen aparecer tres palabras: Hetzner, OVH, bare metal.
Hetzner en 2026, incluso después de subir precios, sigue siendo muy agresivo en pricing. En sus páginas actuales se ve que las líneas dedicated empiezan aproximadamente en EUR42-44 al mes tras el ajuste de precios de abril, mientras que instancias cloud del nivel CPX31 con 4 vCPU, 8 GB RAM y 160 GB SSD cuestan EUR17.99 al mes. Hetzner también ofrece object storage desde EUR5.99 al mes y load balancer desde EUR5.99. (Hetzner)
OVHcloud mantiene un tono más enterprise, pero también resulta interesante para quienes necesitan dedicated servers, private networking y ingress/egress ilimitado en la gama dedicated. En sus páginas oficiales, los Advance dedicated servers empiezan en $107 al mes, y la empresa destaca por separado el tráfico ilimitado de entrada y salida, la protección anti-DDoS integrada, private vRack y 500 GB gratuitos de backup externo. Para proyectos intensivos en tráfico, esto no es un detalle menor, sino una partida de ahorro bastante tangible. (OVHcloud)
La idea principal aquí es simple: cuando la carga es estable y continua, y el perfil del sistema está claro, comprar o alquilar un "trozo de hardware" vuelve a empezar a ganar frente a un conjunto de managed services, sobre todo si el proyecto consume mucho CPU, RAM, storage y tráfico saliente. (OVHcloud)
Cuándo la nube sale más a cuenta
La nube sale más a cuenta no porque sea "barata por sí sola", sino porque en una serie de escenarios permite no pagar por adelantado infraestructura de más.
El primer escenario es la carga con picos. Si el servicio está casi vacío durante el día, pero por la noche, en temporada o en rebajas crece varias veces, la nube permite ajustar recursos a la demanda real. Autoscaling, enfoques serverless y pago por uso suelen resultar más baratos que mantener servidores propios con una gran reserva de capacidad "por si acaso". En el modelo self-hosted, esa reserva hay que comprarla, alquilarla, alojarla y mantenerla igualmente, aunque esté ociosa la mayor parte del tiempo.
El segundo escenario es un arranque rápido y alta incertidumbre. Cuando un producto acaba de lanzarse, para el equipo importa más la velocidad que la economía perfecta por unidad de CPU. En la nube puedes levantar rápidamente un entorno, una base de datos gestionada, object storage, una cola, un balanceador y monitorización sin pasar semanas montando infraestructura. Sí, más adelante puede salir más caro. Pero en la fase inicial, la nube a menudo se compra no por la factura mínima, sino por velocidad y por reducir el dolor operativo.
También existe un tercer caso: una carga estable y predecible dentro de la propia nube. Si la empresa ya sabe que va a necesitar una determinada capacidad de forma permanente, los hyperscalers permiten reducir costes mediante committed use discounts, reserved instances y savings plans. Ya no es una ventaja de elasticidad, sino un descuento por previsibilidad. Google, por ejemplo, habla de descuentos de alrededor del 28 % con compromiso anual y de hasta el 46 % con compromiso a tres años, mientras que Azure menciona ahorros notables frente a pay-as-you-go al usar reservations y savings plan.
Si se mira con frialdad, la nube es especialmente buena allí donde el equipo tiene poco tiempo, mucha incertidumbre y donde los errores de operación salen caros. Pero cuando el sistema se vuelve maduro, predecible y cargado 24/7, la conversación suele cambiar: la pregunta ya no es si la nube es cómoda, sino si esa comodidad se ha vuelto demasiado cara.
Ejemplos reales de cálculo
Lo que viene a continuación no es una verdad eterna, sino ilustraciones de trabajo. Los precios dependen de la región, el SLA, el tráfico, los discos, las reservas y los descuentos. Pero el orden de magnitud ya muestra bastante bien dónde está el punto débil de cada opción.
Escenario 1. Servicio pequeño y estable: API + Postgres + object storage
Supongamos que tenemos un SaaS con backend funcionando de forma constante, una base de datos pequeña, 1 TB de archivos y aproximadamente 1 TB de tráfico saliente al mes.
Si miramos el storage en AWS, solo 1 TB de S3 Standard son aproximadamente 1,024 x $0.023 = $23.55 al mes. Si se envía 1 TB hacia fuera, solo el egress a la tarifa base de $0.09/GB añade otros $92.16. Ya son $115.71, y eso sin contar requests, compute, base de datos ni balanceador. Si la arquitectura incluye NAT Gateway, añade además unos $32.85 al mes solo por las horas de funcionamiento, más el coste por gigabytes procesados. (Amazon Web Services, Inc.)
El object storage de Hetzner empieza en EUR5.99 al mes, incluyendo 1 TB de almacenamiento y 1 TB de egress, y un load balancer cloud parte también de EUR5.99. Incluso si añades una instancia cloud CPX31 por EUR17.99, resulta muy difícil perder frente a AWS con este perfil de carga si el servicio no necesita funciones gestionadas exóticas. (Hetzner)
La conclusión es incómoda, pero honesta: para un servicio pequeño y estable con egress apreciable, self-hosted o una "cloud europea barata" suelen destrozar a los hyperscalers en precio. En este tipo de caso, la nube suele ganar no por la factura, sino por la velocidad de lanzamiento y el catálogo de servicios. (Hetzner)
Escenario 2. Carga constante de compute
En Google Cloud, la instancia e2-standard-4 aparece en el pricing actual a $0.154126276 por hora. Funcionando 24/7, eso son unos $112.51 al mes con 730 horas. Y eso todavía sin contar discos, backups ni costes de red. (Google Cloud)
Hetzner tiene opciones del nivel CPX31: 4 vCPU, 8 GB RAM, 160 GB SSD por EUR17.99/mes, así como planes shared que históricamente han sido incluso más baratos. Aunque no sea una comparación perfecta apples-to-apples en clase de CPU, storage y SLA, la diferencia de precio es tan grande que no desaparece con pequeños ajustes. (Hetzner)
Ahí aparece la regla principal de 2026: si la carga es predecible y el servidor realmente trabaja las 24 horas, la nube pública casi siempre empieza a perder frente a bare metal o frente a un "proveedor cloud de infraestructura barata" de tipo europeo. (Hetzner)
Escenario 3. Managed database frente a "tu propio PostgreSQL"
En las pricing pages oficiales de Azure, PostgreSQL Flexible Server, por ejemplo D4s v6 (4 vCore, 16 GiB), aparece en torno a $259.88/mes en pay-as-you-go, y justo al lado se ve que el reserved pricing puede aportar alrededor de un 40 % de ahorro. (Microsoft Azure)
Esa factura se justifica con bastante facilidad si necesitas un managed service: actualizaciones automáticas, menos trabajo manual, SLA, snapshots cómodos e integración con el resto del ecosistema cloud. Pero si el equipo sabe administrar PostgreSQL y la base de datos no es extremadamente crítica en requisitos de HA, el mismo dedicated server de Hetzner u OVH a menudo permite alojar la aplicación, la base de datos y parte del storage dentro del mismo presupuesto o incluso de uno menor. (Microsoft Azure)
Por eso mismo, una managed DB es el ejemplo clásico en el que la nube a menudo se compra no porque sea más barata, sino porque es más cara, pero más cómoda. Y a veces esa es la decisión correcta. (Microsoft Azure)
Cuándo la nube sale más a cuenta
La nube sale más a cuenta cuando estás en una fase temprana del producto, tienes un equipo pequeño, crecimiento impredecible, experimentos frecuentes, necesidad constante de crear y destruir entornos rápidamente, y además una arquitectura muy apoyada en managed services. Lo mismo aplica a sistemas geodistribuidos, cargas bursty, ML/analítica con jobs esporádicos y casos en los que una caída por error humano o problemas de hardware costaría más que cualquier factura de AWS. Los descuentos de reserved o committed plans refuerzan todavía más esta lógica si de todos modos sigues dentro del ecosistema cloud. (Google Cloud)
Hay otra excepción importante: si tu equipo es flojo en ops, entonces un "servidor barato" puede acabar siendo la solución más cara de la empresa. Cualquier ahorro se esfuma muy rápido cuando llega un fin de semana divertido con degradación de RAID, una backup policy mal hecha y la única persona que sabe dónde está el inventario de Ansible. Eso ya no va de la lista de precios, sino de madurez organizativa. No es casualidad que OVHcloud y los hyperscalers pongan tanto énfasis en SLA, automation y manageability: esas cosas cuestan dinero, pero no se las han inventado de la nada. (OVHcloud)
Cuándo tu propio servidor sale más a cuenta
Self-hosted sale más a cuenta allí donde la carga es uniforme, el sistema vive 24/7, los requisitos de latency y locality están claros, el volumen de egress es notable y el equipo sabe mantener Linux, bases de datos, monitorización y backup/recovery sin magia. Esto se aplica especialmente a:
- servicios internos;
- APIs y SaaS con demanda predecible;
- sistemas intensivos en storage;
- bases de datos con carga constante;
- runners de CI/CD;
- cargas analíticas y ETL;
- proyectos donde importan la jurisdicción europea y una factura fija. (OVHcloud)
Dicho de forma simple: cuanto menos "caos de picos" tengas y más "zumbido constante de fábrica" haya, más probabilidades hay de que self-hosted o bare metal sea simplemente más barato. (OVHcloud)
La infraestructura híbrida suele ser la respuesta más madura
El camino más práctico en 2026 no es la religión, sino lo híbrido. Mantener el core workload donde sea más barato y predecible, y usar la nube allí donde realmente es fuerte.
Por ejemplo, la base de datos y las APIs principales pueden vivir en un dedicated server o en Hetzner/OVH, mientras que el edge público, el CDN, los backups en otra región, servicios gestionados concretos, colas, analítica o carga burst pueden estar en AWS, GCP o Azure. De hecho, OVHcloud incorpora esto directamente en el posicionamiento de sus dedicated servers: private network, capacidad para montar hybrid infrastructure y conectar public cloud y private cloud alrededor de bare metal. (OVHcloud)
Lo bueno del híbrido es que golpea la principal debilidad de ambos extremos. No te obliga a pagar hyperscaler tax por todo, pero tampoco te obliga a cargar sobre tus hombros absolutamente todo el dolor operativo. En la vida real, esa suele ser la estrategia arquitectónica menos tonta. (TechRadar)
Conclusión
En 2026, self-hosted suele ser más barato para cargas estables y que funcionan de forma continua, especialmente si tienes mucho storage, egress y suficiente competencia de ops dentro del equipo. La cloud suele compensar más allí donde importan más la velocidad, la flexibilidad, los managed services y el trabajo con carga impredecible. (Amazon Web Services, Inc.)
Es decir, la pregunta ya no suena a "¿qué es mejor: nube o servidores propios?". La pregunta correcta es: qué partes exactas de tu sistema están pagando de más por comodidad y cuáles ya son lo bastante maduras como para vivir más barato fuera de un hyperscaler. Ahí es donde empieza el dinero de verdad. (Basecamp)