Empiece por los requisitos operativos
Antes de comparar configuraciones, recopile el stack de aplicación, la base de datos, las subidas, las tareas programadas, las integraciones y los cambios previstos de cada proyecto. Identifique quién necesita acceso al contenido, acceso de despliegue y administración del host. Son trabajos distintos. Un cliente que edita una página puede necesitar solo una cuenta de aplicación; un contratista que mantiene el sistema operativo necesita una autoridad sustancialmente más amplia.
Registre también la ventana de mantenimiento aceptable, quién aprueba el tiempo de inactividad, dónde se guardan las copias de recuperación y quién paga el trabajo operativo. Anote cualquier requisito del cliente de un servidor o cuenta separados como restricción de decisión. Una hoja de cálculo de recursos no puede resolver un requisito de titularidad o acceso.
- Nombre al operador principal y a un reemplazo para cada proyecto.
- Enumere las dependencias compartidas: acceso a DNS, credenciales de despliegue, servicios de base de datos y destinos de copia de seguridad.
- Marque los requisitos desconocidos para una decisión del cliente antes de comprometerse con el acuerdo.
Elija el límite de acceso antes del tamaño del servidor
OWASP recomienda conceder solo los permisos necesarios para el trabajo de una persona y validar que se mantengan las restricciones previstas. Aplique ese principio al plan de hosting: use identidades individuales, credenciales de aplicación específicas del proyecto y una ruta de despliegue documentada. Un directorio con el nombre de un cliente es una ayuda organizativa, no una política de acceso.
Si se utiliza Docker, trate el acceso a su daemon como una responsabilidad a nivel de host. La documentación de seguridad de Docker explica que un operador de daemon de confianza puede montar y modificar archivos del host. Por lo tanto, otorgar a un contratista externo control sin restricciones sobre Docker es una mala combinación para un host que contiene datos de un cliente no relacionado.
Las instancias VPS separadas permiten administración del sistema operativo y decisiones de versión independientes. Aun así requieren permisos cuidadosos dentro de cada proyecto. Credenciales de agencia compartidas o una cuenta de despliegue compartida pueden reconectar los riesgos que pretendía separar.
Trabaje con dos briefs de clientes ficticios
Los clientes a continuación son ejemplos ficticios, no historiales de clientes. La agencia opera ambos proyectos hoy, pero sus requisitos de acceso y timing difieren.
Colocar estos dos proyectos juntos haría que el acceso del contratista de Morrow y el calendario de lanzamiento formaran parte del riesgo operativo de Aster. La decisión de servidores separados se deriva de esas restricciones; no afirma que Morrow necesite una cantidad particular de CPUs ni que Aster esté libre de riesgos.
Desplace horizontalmente para ver todas las columnas de la tabla.
| Factor de decisión | Aster Furniture: sitio de folleto | Morrow Workshops: sitio de registro |
|---|---|---|
| Carga de trabajo | Páginas públicas y actualizaciones ocasionales de contenido | Formularios, una base de datos y exportaciones programadas de registros |
| Acceso | El cliente edita el contenido; la agencia despliega | El desarrollador externo necesita administración del host |
| Mantenimiento | Una ventana nocturna acordada | Sin cambios planificados durante un lanzamiento de reservas |
| Impacto de incidentes | Una interrupción temporal de la página se puede discutir | Los envíos perdidos o duplicados requieren investigación |
| Requisito de salida | Exportar contenido y mover la aplicación | Transferir un entorno operado de forma independiente |
| Decisión provisional | Considerar compartir con sitios compatibles operados por la agencia | Usar un VPS separado y credenciales de proyecto separadas |
Compare el coste total de ambas opciones
Cree dos versiones de presupuesto utilizando el configurador actual: una configuración compartida y una configuración por proyecto. Para cada una, enumere por separado el total de hosting para el período seleccionado, las opciones recurrentes, los servicios externos y el tiempo de mantenimiento de la agencia. Evite copiar un precio antiguo en el brief del cliente. Registre cuándo se preparó la configuración y quién aprobó la asignación.
Para un host compartido, acuerde cómo los clientes dividen los costos fijos y qué sucede cuando uno se va o requiere una actualización. Las partes iguales son simples pero pueden ser inadecuadas cuando un proyecto causa la mayor parte del crecimiento de almacenamiento o del trabajo operativo. Los servidores separados hacen más clara la atribución, aunque añaden tareas separadas de parcheo, monitoreo y recuperación.
Deje margen de recursos para lanzamientos, copias de seguridad y trabajo temporal. Los contenedores Docker no tienen restricciones de CPU ni de memoria por defecto; configure límites apropiados y evalúe la carga de trabajo combinada. Una lista de contenedores por sí sola no demuestra un presupuesto de recursos viable.
Haga el mantenimiento y la recuperación específicos de cada proyecto
En un host compartido, un reinicio del sistema operativo afecta a todos los proyectos residentes. Coloque el mantenimiento del host en un calendario común e identifique quién contacta a cada cliente. Mantenga las versiones de las aplicaciones separadas cuando sea práctico y evite programar la exportación de datos de un proyecto durante el lanzamiento importante de otro.
Las notas de recuperación deben identificar la base de datos, los archivos, la configuración y las credenciales necesarias de un proyecto sin copiar secretos en las notas. Planifique la restauración en un destino de prueba separado. Restaurar todo un host compartido como primera respuesta podría reemplazar cambios saludables que pertenecen al otro cliente.
Con instancias VPS separadas, registre los servicios compartidos que permanecen. Una cuenta de DNS común, un destino de respaldo o un operador aún pueden afectar a ambos proyectos. La separación de servidores no es evidencia de infraestructura física independiente ni de disponibilidad garantizada.
Valide la opción y establezca criterios de revisión
Antes de aceptar el acuerdo, haga que un segundo operador verifique que la identidad de un proyecto puede realizar su trabajo asignado y no puede leer los archivos, respaldos o secretos del otro proyecto. Revise los permisos de la base de datos y las credenciales implementadas, así como las pantallas de la aplicación. Utilice datos de prueba inofensivos en un entorno acordado; no sondee los datos de producción de otro cliente.
Registre el resultado como aceptado, rechazado o a la espera de una corrección con nombre. Si no se puede demostrar el aislamiento, restrinja el acceso o mueva el proyecto antes de otorgar permisos más amplios. Una respuesta exitosa de la página de inicio no es una verificación de acceso o recuperación.
- Mantenga un registro de decisiones con la disposición elegida, la asignación de costos aprobada, los responsables y los elementos no resueltos.
- Revise la elección cuando se incorpore un administrador externo, cambie una ventana de lanzamiento, crezca el almacenamiento o un cliente se prepare para irse.
- Utilice la guía de responsabilidades para convertir la elección técnica en un acuerdo operativo.
Fuentes y revisión
Las referencias técnicas se verificaron en septiembre de 12, 2026. Los ejemplos son ejercicios de planificación; la documentación de software referenciada no establece capacidades de servicio de PrivateHostLab.