Cómo elegir un hosting: checklist sin marketing

Elegir hosting suele reducirse a comparar precios de entrada, y de ahí vienen las sorpresas: el plan barato que no soporta tu back end, el dominio cobrado aparte, la renovación que cuesta el doble. Lo más seguro es invertir el orden: primero lo que necesita el proyecto, después el proveedor.

El checklist de abajo sirve para cualquier proveedor y no señala un ganador universal, porque un blog estático y una API con base de datos piden cosas distintas.

¿Qué necesita ejecutar tu proyecto?#

Esta pregunta descarta la mitad de las opciones. Hay tres casos comunes:

• Sitio estático: archivos ya listos, sin código ejecutándose en el servidor. Mira qué es un sitio estático. Es el caso más simple y barato de alojar.
• Aplicación con servidor: Next.js con renderizado en el servidor, una API en Node.js o Python, un panel de administración. Necesita un proceso siempre encendido y RAM.
• Aplicación con base de datos: además del servidor, necesita una base (PostgreSQL, MySQL, MongoDB, Redis) accesible, de preferencia cerca de la aplicación.

Si todavía no tienes clara la diferencia entre estos casos, lee qué es el alojamiento web antes de seguir.

¿Qué criterios importan de verdad?#

Usa esta lista como filtro. Si un proveedor falla en dos o más puntos que te importan, descártalo.

1. Compatibilidad con tu stack. ¿Se soportan el lenguaje y la versión que usas (Node, Python, PHP, Java)? El hosting compartido tradicional suele ser fuerte en PHP y débil en el resto.
2. RAM y CPU. Es el límite que más sitios tumba en producción. Averigua si la cifra es por aplicación o un total repartido entre todas, y si el proveedor aclara qué pasa al superarla.
3. HTTPS incluido. Hoy es un requisito básico. Autoridades como Let's Encrypt emiten certificados sin costo, y se describen como "una autoridad de certificación gratuita, automatizada y abierta". Cobrar mucho por un certificado básico es una señal de alerta. Mira qué es SSL/TLS.
4. Dominio propio. Comprueba que el plan acepte tu dominio y si el dominio se vende junto con el hosting o aparte. Dominio y hosting son servicios distintos. Registrar el dominio a tu nombre, y no al del proveedor, facilita cambiar de hosting después.
5. Logs y métricas. Sin logs, es un cliente quien te avisa que el sitio se cayó. Busca logs en tiempo real y un panel de CPU y RAM.
6. Copias y recuperación. Revisa si hay copias automáticas, cuánto tiempo se guardan y si puedes restaurar tú mismo. Prueba una restauración al menos una vez: una copia que nunca se restauró es solo una suposición.
7. Uptime y soporte. Entiende qué promete el número. Con 99,9% al mes, el sitio puede estar caído unos 43 minutos (30 días × 24 h × 60 min × 0,1%). Mira también qué significa 99,9% de uptime. Pregunta cómo responde el soporte y en qué idioma.
8. Salida fácil. ¿Puedes exportar el código, la base y los archivos? ¿Hay permanencia o multa por cancelar? Prefiere proveedores donde irse es solo cambiar el DNS.

¿Cuánto cuesta de verdad?#

El precio anunciado rara vez es el total. Suma:

• el hosting (mensual o anual);
• el dominio (se cobra por año, y la renovación puede costar más que el primer año);
• la base de datos, si no está incluida;
• excedentes de tráfico, almacenamiento o tiempo de build;
• copias de seguridad, correo profesional y CDN, cuando se cobran aparte.

Haz la cuenta a 12 meses y compara el total, no la mensualidad. Para cifras por tipo de solución, mira cuánto cuesta alojar un sitio web y cuánto cuesta un dominio.

Compartido, VPS o plataforma: ¿qué tipo elegir?#

No existe el mejor tipo, existe el que encaja con tu tiempo y tus conocimientos. Un VPS barato sale caro si pasas las noches aplicando parches. La comparación completa está en VPS, cloud o plataforma.

¿Qué señales de alerta evitar?#

• Promesas de "tráfico ilimitado" o "recursos ilimitados" sin una política de uso justo escrita.
• Precio de entrada solo para el primer periodo, sin el valor de renovación visible.
• Ninguna mención a límites de RAM o CPU.
• Sin acceso a logs o sin forma de exportar tus datos.
• Cargo extra para activar HTTPS.
• Comparativas que en realidad son enlaces de afiliado sin aviso.

¿Cuál elegir en cada escenario?#

• Portafolio o blog estático: hosting estático o plataforma de sitios. El costo puede ser bajo y el HTTPS suele venir listo.
• Sitio corporativo con formulario: estático más un servicio de formularios, o una aplicación pequeña con back end.
• Tienda o aplicación con base de datos: un plan con RAM holgada, base cerca de la aplicación, copias automáticas y logs.
• API o bot: proceso siempre encendido, reinicio automático y logs. Evita planes que suspenden la aplicación por inactividad.
• Proyecto que va a crecer: prioriza la salida fácil y poder subir la RAM sin migrar.

Cómo hacerlo en Square Cloud#

Square Cloud es un hosting self-service: tú haces el deploy y controlas la aplicación. Comparado con el checklist anterior, cubre estos puntos (según las páginas oficiales):

• Stack: diversos runtimes, entre ellos Node.js, Python, PHP, Go, Java y sitios estáticos (en el estático, nginx está siempre en línea sirviendo los archivos). Consulta los runtimes disponibles hoy en Runtimes.
• RAM: el plan define un pool compartido entre tus aplicaciones, con un mínimo de 512 MB por aplicación web. Todos los planes son de pago, y el Hobby parte de R$12,49 al mes.
• HTTPS y dominio: cada aplicación web recibe un subdominio *.squareweb.app con HTTPS. El dominio personalizado está disponible desde el plan Standard y sigue registrado a tu nombre en tu registrador.
• Base de datos: hosting de MongoDB, PostgreSQL, MySQL y Redis desde Standard. El Hobby no incluye base de datos.
• Logs y métricas: logs en tiempo real y analytics web sin cookies en todos los planes.
• Sin suspensión: los contenedores permanecen encendidos, y el reinicio automático (activado por defecto en el deploy desde el panel) levanta de nuevo la aplicación que termina con error.
• Salida: sin permanencia.

Mira las opciones para sitios web en la página de sitios de Square Cloud.