Definición
El hosting es el servicio que mantiene tu web o tu aplicación accesible en internet: te da el espacio, la máquina y la conexión para que cualquiera pueda llegar a ella.
Conviene separar tres cosas que se confunden a diario:
- Dominio: el nombre. Se alquila a un registrador y es tuyo mientras lo renueves.
- DNS: la agenda que traduce ese nombre a una dirección.
- Hosting: dónde están de verdad los ficheros.
Se pueden tener los tres en sitios distintos, y a veces conviene: separar el dominio del hosting facilita mucho cambiarse de proveedor.
Qué mirar antes de contratar
Qué tecnología soporta. Si tu aplicación necesita una versión concreta de PHP, Node o una base de datos determinada, eso decide más que el precio.
Cómo se sube el código. Panel web, FTP, SSH, despliegue automático desde un repositorio. Determina si desplegar es un minuto o una tarde.
Copias de seguridad. Si las hace el proveedor, cada cuánto, cuánto histórico guarda y — la pregunta que casi nadie hace — si puedes restaurarlas tú o dependes de abrir un ticket.
Certificado HTTPS. Hoy debería estar incluido y renovarse solo.
Correo. Muchos hostings lo incluyen. Y conviene saber que tener el correo en el mismo sitio que la web ata las dos cosas a la hora de migrar.
Límites reales. El «ilimitado» de los planes compartidos nunca lo es: hay límites de procesos, de memoria o de peticiones que no aparecen en la portada.
Cómo te atas sin querer
Esta es la parte que casi nunca se piensa al contratar y siempre se sufre al migrar:
- Correo en el mismo proveedor. Migrar buzones con años de histórico es lo que más frena un cambio.
- Bases de datos con extensiones propias del proveedor.
- Paneles que generan configuraciones que solo entienden ellos.
- Dominio registrado con el mismo proveedor, que puede poner trabas o simplemente tardar en darte el código de traspaso.
Nada de eso impide marcharse. Todo lo hace lento y molesto, que a efectos prácticos es parecido.
Ejemplo práctico
Lo que aprendí gestionando varios sitios en el mismo proveedor: el hosting deja de ser un problema el día que desplegar está automatizado y las copias están probadas. Mientras el despliegue sea «subir ficheros por FTP y rezar», cualquier cambio da pereza y cualquier fallo asusta.
Con un script que empaqueta, sube y extrae en el servidor, y una copia de la base de datos antes de cada operación delicada, el proveedor pasa a ser intercambiable. Y esa es exactamente la posición en la que conviene estar.
El segundo aprendizaje, sobre lo que de verdad diferencia a un proveedor: no es el precio ni las prestaciones anunciadas. Es qué pasa cuando algo va mal. Un hosting barato con soporte que tarda dos días en contestar es caro el día que la web está caída.
Y hay un detalle técnico que sí marca diferencia real y que rara vez aparece en las comparativas: si el servidor está en la zona horaria correcta. Un servidor en UTC descuadra fechas en informes y en tareas programadas, y el fallo aparece tarde y despista mucho. Ver tarea programada.
Y una advertencia sobre los planes compartidos: comparten recursos. Si otra web del mismo servidor recibe un pico o tiene un proceso desbocado, tu web se ralentiza sin que tú hayas cambiado nada. Diagnosticar eso desde fuera es casi imposible, y es la razón principal para pasar a un VPS cuando el proyecto empieza a importar.
Errores comunes
- Confundir dominio, DNS y hosting.
- Contratar por precio sin comprobar la tecnología que necesitas.
- No comprobar las copias ni intentar restaurar una nunca.
- Registrar el dominio con el mismo proveedor sin necesidad.
- Fiarse del «ilimitado».
- No automatizar el despliegue.
- No revisar la zona horaria del servidor.
- Dejar sin vigilar si el sitio está caído. Enterarte por un cliente es enterarte tarde.
Cuándo revisarlo
Al renovar, y siempre que el proyecto cambie de escala o de tecnología.
La pregunta que mide tu libertad: si mañana quisiera cambiar de proveedor, ¿cuánto tardaría? Si la respuesta es «no lo sé» o «semanas», estás más atado de lo que creías — y eso se arregla antes de necesitarlo, no después.
