Alojar varios sitios de clientes en un solo VPS — sin cuotas por cuenta

Aquí va un número que sorprende la primera vez que lo calculas: un Hetzner CAX21 de 13 €/mes (4 vCPU, 8 GB de RAM) aloja cómodamente una docena de sitios WordPress de pequeñas empresas y aún le sobra margen. El hardware para mover muchos sitios en una sola máquina lleva años siendo barato. Entonces, ¿por qué alojar a cinco clientes cuesta tantas veces cinco veces más?

La respuesta está en la licencia, no en el cómputo. cPanel, Plesk y la mayoría de plataformas gestionadas cobran por cuenta — cada cliente que añades sube tu factura, trabaje el servidor más o no. Esta guía trata de escapar de eso: cómo mover varios sitios de clientes en un único VPS de forma segura, qué exige de verdad ese «de forma segura», y cómo hacerlo sin pagar una tasa por cada cuenta.

La tasa por cuenta, en números reales

El precio por cuenta parece inofensivo con dos clientes. Se agrava al crecer. Esto es, a grandes rasgos, lo que cuesta el mismo puñado de sitios según las opciones habituales (precios de lista, mediados de 2026):

Las cifras exactas se mueven con promociones y niveles, pero la forma no cambia nunca: el precio por cuenta hace que tu coste crezca con tu éxito. El cliente 40 te cuesta lo mismo en cómputo que el 4 y genera lo mismo — pero la licencia se come la margen en silencio. Un modelo plano rompe ese vínculo: pagas una vez, y cada cliente adicional es margen puro frente a una factura de VPS que apenas se mueve.

Ese es el argumento comercial. Pero si la gente no amontona sin más todos los sitios en una máquina, es por una razón técnica — y esa es la parte que conviene acertar.

El verdadero reto: el aislamiento, no la capacidad

Poner diez sitios en un servidor es fácil. Poner diez sitios en un servidor de forma segura — para que un sitio hackeado o mal educado no pueda leer, hambrear ni tumbar a los otros nueve — ese es el oficio real del alojamiento multiinquilino. Estos principios valen en cualquier máquina Linux, con cualquier panel o ninguno:

1. Un usuario Linux por sitio

La regla más importante. Cada sitio debe correr bajo su propio usuario de sistema dedicado, con los archivos en propiedad de ese usuario y permisos que impidan a los demás leerlos. Si todos los sitios corren como www-data, un único plugin de WordPress comprometido puede leer el wp-config.php de todos los demás sitios — contraseñas de base de datos incluidas. Usuarios separados convierten una brecha a nivel de sitio en un problema de ese sitio, no de todo el servidor.

2. Un pool PHP-FPM dedicado por sitio

No compartas un único pool de procesos PHP entre inquilinos. Da a cada sitio su propio pool PHP-FPM corriendo bajo su usuario Linux. Esto hace dos cosas: impone el aislamiento anterior en la capa de PHP, y permite limitar recursos por sitio (pm.max_children, límites de memoria) para que un sitio con carga no consuma todos los workers PHP y bloquee a los demás. Extra: cada pool puede correr una versión de PHP distinta — cliente legacy en 7.4, app moderna en 8.4, en el mismo servidor.

3. open_basedir, para que PHP no se pierda

Incluso con usuarios separados, un script mal configurado puede intentar leer fuera de su directorio. Define open_basedir por pool para fijar el PHP de cada sitio a su propia raíz (y a su directorio temporal). Es una red de seguridad barata, defensa en profundidad: si el aislamiento nº 1 falla alguna vez, esta atrapa al fugado.

4. Una base de datos y un usuario SQL por sitio

Nunca compartas un usuario MySQL/MariaDB entre sitios de clientes, y nunca des a un sitio una cuenta con privilegios globales. Cada sitio recibe su propia base de datos y un usuario dedicado con permisos solo sobre esa base. Una credencial filtrada expone entonces los datos de un cliente, no todo tu parque.

5. Cuotas de disco, para que nadie hambree la máquina

En una máquina compartida, los logs desbocados, los uploads inflados o las copias olvidadas de un cliente pueden llenar el disco — y un disco lleno tumba todos los sitios, incluido el propio panel. Fija una cuota de disco por sitio. Convierte «el servidor está caído» en «un cliente alcanzó su límite»: un ticket de soporte, no una caída.

6. Logs, copias y cortafuegos independientes

Da a cada sitio sus propios logs de acceso/error para diagnosticar a un cliente sin rebuscar en un torrente compartido. Respalda cada sitio de forma independiente para restaurar uno sin tocar los demás. Y endurece la máquina en su conjunto — cortafuegos (UFW), baneo antifuerza bruta (Fail2ban) e idealmente una capa de comportamiento (CrowdSec) — porque en un servidor multiinquilino, un ataque a un sitio es un ataque a todo el vecindario.

Haz los seis y un VPS se vuelve un hogar realmente seguro para muchos clientes. Sáltate uno solo y habrás construido un punto único de fallo catastrófico, propagado de un inquilino a otro.

Hacerlo a mano es engorroso — y sutilmente propenso a errores

Ninguno de los seis es exótico. Pero cablearlos bien para cada nuevo sitio — un usuario Linux nuevo, un pool FPM con el open_basedir y los límites correctos, una base y un usuario aislados, una cuota, rutas de logs, un vhost, un certificado autorrenovado — son muchas piezas móviles que ensamblar a mano, cada vez, sin la errata que rompe en silencio el aislamiento que creías tener. Esa es justo la configuración repetitiva y crítica para la seguridad que un panel de control existe para estandarizar.

Aquí es donde un panel que posees demuestra su valor. ShadowPanel aprovisiona cada nuevo sitio con toda la lista de aislamiento aplicada por defecto:

• Un usuario Linux dedicado por sitio, archivos en propiedad de ese usuario con grupo www-data y permisos cerrados.
• Un pool PHP-FPM aislado corriendo bajo ese usuario, con open_basedir impuesto y su propia versión de PHP (5.6 → 8.4).
• Su propia base y usuario SQL, acotados a ese único sitio.
• Cuotas de disco por sitio que fijas en la interfaz, más seguimiento de uso en vivo.
• vhost de nginx y logs separados, además de SSL gratuito de Let's Encrypt con renovación automática por dominio.
• Una máquina endurecida por defecto — UFW, Fail2ban, CrowdSec y escaneo ClamAV en los uploads.

Y es una licencia plana, no un cargo por cuenta — así que el aislamiento que tendrías que montar a mano para cada cliente viene gratis con cada cliente.

Una configuración concreta: cinco clientes en un CAX21

Un recorrido realista:

1. Aprovisiona un VPS — un Hetzner CAX21 (4 vCPU, 8 GB de RAM, ~13 €/mes) es un punto de partida sensato para una docena de sitios pequeños.

2. Instala ShadowPanel y activa tu licencia:

   curl -fsSL https://shadowpanel.de/install.sh | bash
   

3. Añade el sitio de cada cliente. Apunta el dominio, y el panel aprovisiona el usuario Linux, el pool FPM, la base, la cuota, el vhost y el SSL en un paso — la lista de aislamiento completa, aplicada idéntica cada vez.

4. Fija una cuota de disco por sitio para que ningún cliente pueda llenar la máquina.

5. Vigila el uso de recursos. A medida que el servidor se llena, los límites por pool impiden que un sitio con carga hambree al resto; cuando superes la máquina, mueve un cliente pesado a un segundo VPS — la licencia plana no te penaliza por ejecutar más de un panel.

Cinco clientes, un servidor, una factura predecible — y cada sitio sellado de los demás.

Salvedades honestas

• Una máquina es una sola cesta. El aislamiento protege a los inquilinos entre sí; no los protege de un fallo a nivel de host. Para todo lo crítico, reparte los clientes entre dos o tres VPS en vez de apostar toda una cartera a una sola máquina.
• La RAM es el techo real, no la licencia. Una docena de sitios folleto inactivos no pesa nada; una docena de tiendas WooCommerce activas, sí. Vigila la memoria y sube un nivel de VPS (o pasa a una segunda máquina) antes de hacer swap.
• Un panel automatiza la configuración, no el criterio. ShadowPanel aplica el aislamiento por ti, pero la planificación de capacidad, las actualizaciones y las copias siguen siendo tuyas. Ese es el precio de poseer la pila en vez de alquilarla por cuenta.

En resumen

Alojar muchos sitios de clientes en un solo VPS nunca lo bloqueó el hardware — un servidor barato tiene la capacidad desde hace años. Lo bloqueaban dos cosas: acertar con el aislamiento por sitio, y no pagar una tasa por cuenta por el privilegio. Domina los seis principios de aislamiento — usuarios separados, pools FPM por sitio, open_basedir, bases aisladas, cuotas, logs y copias independientes — y una máquina aloja con seguridad una docena de clientes. ShadowPanel aplica toda esa lista a cada sitio por defecto, sobre una única licencia plana, para que tus costes sigan planos mientras tu cartera crece.

Si haces esto para revender alojamiento bajo tu propia marca, combínalo con la marca blanca: consulta Hosting de marca blanca para agencias.

Ver precios → · Descargar ShadowPanel →