Hosting web barato y confiable: elige la arquitectura antes de contratar un servidor

Si estás buscando un hosting web barato y confiable, la primera decisión no debería ser qué servidor contratar.

Debería ser:

¿Qué parte de mi negocio necesita realmente un servidor?

Tal vez quieres validar una idea de SaaS. Tal vez tu equipo necesita una herramienta interna. Quizá tienes un catálogo de productos o una página antigua alojada en GoDaddy que nadie quiere tocar.

No todos esos casos son el mismo problema técnico.

Una web corporativa puede necesitar únicamente una entrega rápida de contenido estático. Un catálogo puede requerir una pequeña capa de datos. Una aplicación interna puede necesitar autenticación, permisos, transacciones, tareas en segundo plano y PostgreSQL.

El hosting barato y confiable no es simplemente el plan con el precio mensual más bajo. Es la arquitectura más pequeña capaz de realizar el trabajo real sin crear un riesgo operativo innecesario.

Una página web no es lo mismo que una aplicación

Imaginemos tres negocios:

1. Una empresa local necesita páginas de servicios, ubicación, contacto y algunos artículos.
2. Un comercio necesita categorías, precios, disponibilidad y un panel para editar productos.
3. Un equipo necesita registrar clientes, generar documentos, procesar pagos, manejar inventario y ejecutar tareas automáticas.

Los tres pueden decir: “Necesitamos una página web”. Técnicamente, necesitan tres productos diferentes.

El primero es principalmente contenido. El segundo añade una capa de datos controlada. El tercero es una aplicación con reglas de negocio y estado operativo.

La infraestructura debe crecer junto con esa complejidad, no antes.

La arquitectura sencilla para una web moderna

Para una web corporativa, un blog, una landing page o un catálogo público moderado, una arquitectura habitual puede ser:

Astro
  ↓
Cloudflare Pages / Workers
  ↓
Base de datos D1 opcional para contenido administrable pequeño
  ↓
Deploy basado en Git

Astro está diseñado para generar la mayor parte de la página como HTML estático y añadir JavaScript únicamente a los componentes interactivos que lo necesitan. Esto se conoce como Islands Architecture. La documentación oficial de Astro sobre Islands explica cómo este enfoque evita enviar una aplicación JavaScript completa a cada visitante.

Para un pequeño negocio, esto puede significar que:

• La página pública se carga desde el edge;
• El navegador recibe muy poco JavaScript por defecto;
• Los cambios de contenido pueden desplegarse desde Git;
• No hay un proceso Node.js encendido todo el día para servir una página corporativa;
• La superficie operativa es menor que la de una instalación CMS tradicional.

Esto resulta especialmente útil al migrar una web antigua de GoDaddy. Migrar no siempre significa reconstruir toda la operación de la empresa. A veces el primer paso correcto es reemplazar una web lenta y difícil de mantener por un proyecto rápido, versionado y más fácil de evolucionar.

Qué resuelve Cloudflare Pages y qué no

Cloudflare Pages puede servir archivos estáticos desde su red global. La documentación actual de Cloudflare indica que las solicitudes de assets estáticos son gratuitas e ilimitadas tanto en el plan gratuito como en los planes de Pages Functions. Eso no significa que toda solicitud dinámica sea gratuita o ilimitada.

Cuando una solicitud ejecuta una Pages Function, se contabiliza y limita como una solicitud de Workers. En el plan Workers Free, el límite de la cuenta es de 100.000 solicitudes diarias. El plan Workers Paid comienza en $5 al mes e incluye 10 millones de solicitudes mensuales, con cargos por el uso adicional. Consulta la documentación oficial de precios de Pages Functions y precios de Workers.

La diferencia práctica es sencilla:

• Una landing page estática es principalmente un problema de distribución de archivos;
• Un formulario, un panel autenticado o una API de catálogo son problemas de cómputo y datos;
• Un proceso que dura minutos es un problema de diseño de cargas de trabajo.

Cloudflare encaja muy bien en la primera categoría y también puede resolver muchas aplicaciones pequeñas. No es una razón para tratar todos los backends como si fueran páginas estáticas.

¿Dónde encaja D1?

Cloudflare D1 es una base de datos SQL serverless que puede funcionar bien con modelos de datos pequeños y de complejidad media, por ejemplo:

• Artículos y categorías de un blog;
• Un catálogo moderado de productos;
• Formularios recibidos;
• Configuración de una web administrable;
• Un dashboard interno sencillo;
• Registros estructurados de bajo volumen.

D1 no es una base de datos sin límites. La documentación actual de Cloudflare indica un tamaño máximo de 500 MB por base de datos en Workers Free y de 10 GB por base de datos en Workers Paid. El plan gratuito incluye 5 millones de filas leídas al día, 100.000 filas escritas al día y 5 GB de almacenamiento total por cuenta. El plan de pago incluye límites mensuales mayores y cobra el uso adicional.

También hay un detalle importante de rendimiento: cada base de datos D1 procesa sus consultas esencialmente de forma secuencial. Si una consulta tarda 1 milisegundo, su rendimiento teórico es muy distinto al de una consulta que tarda 100 milisegundos. Las consultas sin índices y los escaneos completos de tablas pueden convertirse en un problema antes de que la aplicación tenga muchos usuarios.

Consulta los límites oficiales de Cloudflare D1 y sus precios antes de elegir un plan para producción.

Figura 1: una web pública, una capa de datos pequeña y un backend de procesos largos son cargas distintas. Elige la infraestructura según el trabajo, no según la etiqueta “página web”.

D1 es una opción razonable cuando las tablas se mantienen controladas, las consultas están indexadas, las escrituras no son muy concurrentes y la aplicación no depende de procesos largos. Es menos conveniente cuando el sistema necesita funcionalidades avanzadas de PostgreSQL, procesamiento pesado de documentos, transacciones complejas o workers permanentes.

El límite más delicado cuando Cloudflare se conecta con PostgreSQL

Si un Worker de Cloudflare se conecta a una base de datos PostgreSQL tradicional mediante Hyperdrive, la métrica relevante no es únicamente el tráfico HTTP. Hyperdrive cuenta las sentencias SQL.

Nota técnica para equipos que evalúan la arquitectura

Una request del dashboard que ejecuta cinco sentencias SQL consume cinco consultas de Hyperdrive. Por ejemplo:

20.000 requests de API × 5 sentencias SQL = 100.000 consultas de Hyperdrive al día

Eso alcanza el límite de Hyperdrive del plan Workers Free aunque la aplicación haya recibido solo 20.000 requests de API. Las sentencias cacheadas y no cacheadas cuentan, y superar el límite diario hace que las operaciones posteriores de ese tipo fallen hasta el siguiente reinicio del límite.

Por eso, el primer límite de una herramienta interna o de un SaaS inicial puede no ser la cantidad de usuarios concurrentes. Puede ser:

• La cantidad de consultas que ejecuta cada pantalla;
• El polling frecuente;
• Las consultas duplicadas;
• Los endpoints que ejecutan demasiadas consultas;
• La generación de PDFs o el procesamiento de archivos;
• Los flujos administrativos con muchas lecturas y escrituras.

Cloudflare documenta 100.000 consultas de base de datos por día en el plan Workers Free y consultas ilimitadas en Workers Paid. El pooling de conexiones y el caché de consultas de Hyperdrive están incluidos y no generan un cargo adicional independiente. Revisa la documentación oficial de precios de Hyperdrive y sus límites antes de elegir una arquitectura.

Estos ejemplos sirven para planificar, no son una promesa de cuántos usuarios soportará un sistema:

Escenario	Usuarios o visitantes activos por día	Requests aproximadas	Interpretación para planificar
Catálogo pequeño	1.000 visitantes	2.000–10.000	Free podría ser técnicamente suficiente
SaaS inicial	20 operadores más un catálogo	5.000–30.000	Free podría funcionar con consultas eficientes
SaaS con tracción	100 operadores más un catálogo	30.000–100.000	Conviene vigilar el volumen de consultas
Uso intensivo	100+ operadores, polling y muchas consultas	Más de 100.000	Conviene evaluar Workers Paid
Disponibilidad crítica	Cualquier volumen	—	Paid es el inicio más conservador

La conclusión no es que Cloudflare no sea adecuado para PostgreSQL. Hyperdrive está diseñado precisamente para mejorar la conexión con bases de datos SQL tradicionales y regionales. La conclusión es que una pantalla conectada a una base de datos debe medirse por sentencias por request, no solo por requests HTTP.

Qué aporta un VPS como Hetzner

Un servidor cloud de Hetzner representa otro modelo operativo. En lugar de ejecutar funciones pequeñas bajo demanda, alquilas una máquina completa y decides qué servicios funcionan en ella.

Ahí puedes ejecutar:

• Servicios Node.js o Python;
• PostgreSQL;
• Redis;
• Workers permanentes;
• Tareas cron;
• Procesamiento de archivos;
• Generación de PDFs;
• Colas y tareas programadas;
• Servicios internos que necesitan una red privada.

La principal ventaja es el control. Si necesitas ejecutar un proceso durante varios minutos, instalar una librería nativa, mantener un worker permanente o usar extensiones de PostgreSQL, un VPS suele ser más natural que forzar esa carga dentro de una función serverless.

La contrapartida es la responsabilidad. Un VPS barato no es una aplicación administrada. Tu equipo o tu socio técnico debe considerar:

• Actualizaciones del sistema operativo;
• Firewall y configuración de SSH;
• Certificados TLS;
• Permisos de usuarios;
• Backups y pruebas de restauración;
• Monitoreo y logs;
• Rotación de secretos;
• Protección contra abuso;
• Recuperación ante fallos;
• Planificación de capacidad.

La documentación de Hetzner aclara que sus backups y snapshots son copias del disco del servidor y no incluyen los Volumes adjuntos. También documenta un máximo de siete espacios de backup automáticos. Revisa la documentación oficial de backups y snapshots de Hetzner antes de considerar el backup del servidor como una estrategia completa para PostgreSQL.

El servidor puede ser barato. La operación alrededor del servidor no es automáticamente gratuita.

Comparación práctica

Necesidad	Astro + Cloudflare	Backend en VPS
Web corporativa	5/5 Excelente	2/5 Posible, pero suele ser excesivo
Landing page para anuncios	5/5 Excelente	1/5 Normalmente innecesario
Catálogo público pequeño	4/5 Buen encaje con una capa de datos	3/5 Posible
Panel administrativo sencillo	3/5 Adecuado con Functions y D1	5/5 Excelente
PostgreSQL avanzado	1/5 No es su objetivo principal	5/5 Excelente
Procesos largos	2/5 Limitado	5/5 Excelente
Workers permanentes	2/5 Limitado	5/5 Excelente
OCR o procesamiento pesado	2/5 Puede requerir servicios adicionales	4/5 Más natural
Distribución estática global	5/5 Excelente	2/5 Requiere arquitectura adicional
Control del sistema operativo	1/5 Bajo	5/5 Alto
Mantenimiento de infraestructura	5/5 Menor carga operativa	2/5 Mayor carga operativa

5/5 significa el mejor encaje para esa necesidad; 1/5, el menor. En mantenimiento, un puntaje mayor significa menos trabajo operativo para el negocio.

No es una competencia entre Cloudflare y Hetzner. Resuelven problemas diferentes.

Una arquitectura híbrida suele ser una respuesta práctica

No tienes que colocar cada parte de tu negocio en un solo proveedor:

Web pública y catálogo
  → Astro + Cloudflare

Panel administrativo sencillo
  → Cloudflare Functions + D1

Procesamiento largo o pesado
  → Worker Node.js o Python en un VPS

Archivos y documentos generados
  → R2 u otro almacenamiento de objetos

Deploy
  → CI/CD basado en Git

Así cada capa utiliza una infraestructura acorde con su comportamiento. Una empresa no debería pagar y mantener un servidor completo para una web que solo publica contenido. Tampoco debería forzar un sistema operativo crítico dentro de un entorno que no fue diseñado para procesos largos o cargas transaccionales complejas.

Preguntas que conviene responder antes de migrar

Antes de migrar una web antigua o construir una herramienta interna, responde:

1. ¿Qué contenido debe poder editar el negocio?
2. ¿Cuántas personas utilizarán el panel?
3. ¿Cuántas lecturas y escrituras ocurren al día?
4. ¿Qué datos deben almacenarse y durante cuánto tiempo?
5. ¿Se necesita historial o auditoría?
6. ¿Hay procesos que duran más que una solicitud normal?
7. ¿Qué ocurre si la base de datos no responde?
8. ¿Quién se encarga de los backups y de probar la restauración?
9. ¿Qué servicios externos añaden costos recurrentes?
10. ¿Qué debe estar preparado para crecer durante los próximos 12 meses?

Estas preguntas suelen demostrar que la primera versión puede ser más pequeña que la infraestructura propuesta originalmente, o que un hosting compartido barato puede crear más riesgo del que elimina.