Cómo alojar varios sitios web en un VPS sin liarte

Quieres alojar más de un sitio web, pero no quieres que tu servidor se convierta en un cajón de sastre: carpetas misteriosas, dominios rotos, un proyecto que deja a otro fuera de servicio y ninguna idea clara de dónde está cada cosa.

Es un miedo razonable. Un solo servidor puede gestionar varios sitios perfectamente. El truco está en dejar de pensarlo como «una máquina para un único sitio» y empezar a verlo como un pequeño edificio con muchas habitaciones separadas.

Un servidor puede tener más de una puerta de entrada

Un servidor no es más que un ordenador conectado a internet. Como tu portátil, puede ejecutar varias cosas a la vez. Un sitio podría ser un blog de WordPress. Otro, una pequeña web app. Otro más, una herramienta privada para tu equipo.

Alojar varios sitios web en un solo servidor significa que cada proyecto comparte la misma casa física, pero sigue teniendo su propia puerta de entrada.

La puerta de entrada suele ser un nombre de dominio, como example.com, shop.example.com o another-site.com. A los visitantes no les importa que estos nombres acaben en el mismo servidor. Escriben la dirección y aparece el sitio correcto.

El lío empieza cuando cada proyecto se trata como un único montón indistinto. Los archivos se mezclan. Los dominios apuntan al lugar equivocado. HTTPS funciona en un sitio pero no en otro. Arreglar un proyecto rompe sin querer todos los demás.

Una configuración ordenada da a cada proyecto una identidad clara: su nombre, su destino, su conexión segura y su propio espacio en el que vivir.

Los dominios son señales, no sitios web

Un dominio no contiene tu sitio web. Se parece más a una señal en la carretera.

Cuando alguien visita tu dominio, internet comprueba a dónde apunta ese nombre. Ese sistema de apuntado se llama DNS, abreviatura de Domain Name System. El DNS es la agenda de contactos de internet. Conecta un nombre legible con el servidor que debe responder.

Si tienes tres dominios en un solo servidor, los tres pueden apuntar a la misma dirección del servidor. Es lo normal.

Pero apuntar el dominio es solo la primera mitad del trabajo. Lleva al visitante hasta el edificio. No decide en qué habitación debe entrar.

Por eso configurar el dominio y gestionar el enrutamiento en el servidor son dos tareas distintas. El DNS dice: «Ve a este servidor». El enrutamiento dice: «Para este dominio, muestra este proyecto».

Si quieres una explicación de la parte de los dominios en términos sencillos, esta guía es un buen complemento: Cómo conectar un dominio a tu servidor.

El enrutamiento es el recepcionista en la puerta

Una vez que un visitante llega a tu servidor, algo tiene que leer el dominio que ha pedido y enviarlo al proyecto correcto.

Ese «algo» se suele llamar servidor web o proxy inverso. Un proxy inverso es un director del tráfico. Se sitúa en la entrada, mira el dominio solicitado y reenvía al visitante al sitio o a la app correcta entre bastidores.

Piénsalo como el recepcionista de un edificio de oficinas.

Alguien entra y dice: «Vengo al estudio de diseño». El recepcionista lo manda a la oficina 201. Otra persona dice: «Vengo a ver al contable». Va a la oficina 304. Mismo edificio, destinos diferentes.

En tu servidor, example.com podría enrutar a un sitio de marketing. app.example.com podría enrutar a una web app. blog.example.com podría enrutar a WordPress.

Un buen enrutamiento mantiene sencilla la dirección pública, dejando que cada proyecto funcione a su manera. Un sitio podría ser páginas estáticas. Otro podría usar una base de datos. Otro más podría ejecutarse como un servicio de aplicación. Los visitantes no ven esa complejidad. Solo ven el sitio correcto.

Si estás publicando una app en lugar de un sitio web clásico, se aplica la misma idea. La app necesita un lugar donde ejecutarse, y el dominio tiene que enrutar hacia ella. Cubrimos ese camino en Cómo publicar una pequeña web app sin DevOps.

HTTPS es un candado para cada dirección

HTTPS es la versión segura de la conexión a un sitio web. Es lo que muestra a los visitantes el icono del candado en el navegador y protege el tráfico entre ellos y tu sitio.

Cuando alojas varios sitios web, normalmente necesitas HTTPS para cada dominio o subdominio. El candado pertenece a la dirección que la gente visita, no solo al servidor en su conjunto.

Eso significa que example.com, shop.example.com y another-site.com deben quedar cubiertos correctamente cada uno por su cuenta.

Sin esto, los visitantes podrían ver avisos alarmantes en el navegador. O un dominio podría mostrar por error un certificado destinado a otro. Eso da una impresión poco profesional y, cuando se trata de formularios, inicios de sesión, tiendas o paneles de administración, no es algo opcional.

La buena noticia es que HTTPS no tiene por qué ser caro ni misterioso. Los certificados gratuitos son habituales, y pueden renovarse de forma automática cuando la configuración está limpia. Lo importante es asegurarte de que cada sitio tenga su propia ruta segura desde el navegador hasta el proyecto correcto.

Para una explicación en lenguaje sencillo, consulta Cómo conseguir HTTPS gratis en tu propio servidor.

Mantén los proyectos en habitaciones separadas

Compartir un servidor no debería significar compartirlo todo.

Cada sitio web o app debería tener su propio espacio. Como mínimo, eso significa que sabes qué archivos, dominio, base de datos y servicios en segundo plano pertenecen a cada proyecto. Si algún día hay que retirar un sitio, no deberías tener que hacer arqueología.

La separación también reduce los accidentes. Si actualizas un proyecto, los demás no deberían verse afectados. Si una app llena su carpeta de subidas, no debería tragarse en silencio el servidor entero. Si un sitio tiene un problema, deberías poder razonar sobre él sin abrir todos los cajones de la casa.

Hay distintas formas de crear esta separación. Algunas personas usan carpetas y usuarios separados. Otras usan contenedores, que son como fiambreras etiquetadas para las apps y sus ingredientes. Otras usan una mezcla.

El método exacto importa menos que el resultado: cada proyecto tiene un límite.

También deberías pensar en las copias de seguridad. Cuando alojas varios proyectos en un solo servidor, un único error grave puede afectar a más de un sitio. Una copia de seguridad útil no es solo «algunos archivos en alguna parte». Es algo que realmente puedes restaurar. Si aún no lo has planificado, lee Cómo hacer una copia de seguridad de tu servidor — y poder restaurarla de verdad.

El atajo

Todo lo anterior se puede hacer a mano. La pega es que solo sigue siendo viable mientras aún recuerdes cómo lo montaste: qué dominio apunta a dónde, qué sitio recibió qué certificado, qué carpeta pertenece a qué proyecto. Con tres sitios y unos meses de por medio, esa memoria es lo primero que se pierde, y suele ser justo cuando un pequeño cambio rompe otra cosa sin hacerse notar.

Server Manager está pensado para llevar esos detalles por ti. Cuando añades un sitio, le da al proyecto su propio lugar donde vivir, hace que el dominio correcto apunte a él y emite HTTPS para esa dirección exacta — el enrutamiento y los certificados por sitio que recorrían las secciones anteriores, resueltos de una sola pasada en lugar de en varios pasos delicados, y renovados por sí solos para que un candado nunca caduque en silencio. Cada proyecto conserva su propio límite, así que actualizar o retirar uno no toca a los demás, y un sitio que llena su disco o se cae sigue siendo problema de ese único sitio.

La verdadera ventaja es que sigue siendo legible. Meses después puedes abrirlo y ver de un vistazo qué sitio responde a qué dominio y si cada uno está seguro, en lugar de leer archivos de configuración y adivinar. Consigues el resultado que querías al principio — varios sitios web en un solo servidor, cada uno tras su propia puerta de entrada — sin convertirte en la persona que tiene que recordar cada detalle oculto para mantenerlos todos en pie.

Tu victoria: un servidor, muchos sitios ordenados

No necesitas un servidor aparte para cada pequeño sitio web o app. Necesitas etiquetas claras, rutas limpias, direcciones seguras y una separación sensata.

Cuando esas piezas están en su sitio, un solo servidor puede resultar tranquilo en lugar de abarrotado. Cada proyecto tiene su puerta. Los visitantes llegan a donde deben. HTTPS funciona donde debe. Y cuando vuelves meses después, la configuración sigue teniendo sentido.