Comece pelos requisitos operacionais
Antes de comparar configurações, colete a stack de aplicação, o banco de dados, os uploads, as tarefas agendadas, as integrações e as alterações esperadas de cada projeto. Identifique quem precisa de acesso a conteúdo, acesso de implantação e administração do host. Essas são funções diferentes. Um cliente que edita uma página pode precisar apenas de uma conta de aplicação; um prestador que mantém o sistema operacional precisa de autoridade substancialmente mais ampla.
Registre também a janela de manutenção aceitável, quem aprova indisponibilidade, onde ficam as cópias de recuperação e quem paga pelo trabalho operacional. Anote qualquer exigência do cliente por um servidor ou conta separada como restrição de decisão. Uma planilha de recursos não resolve uma exigência de propriedade ou acesso.
- Nomeie o operador principal e um substituto para cada projeto.
- Liste dependências compartilhadas: acesso ao DNS, credenciais de implantação, serviços de banco de dados e destinos de backup.
- Marque requisitos desconhecidos para uma decisão do cliente antes de se comprometer com o acordo.
Escolha a fronteira de acesso antes do tamanho do servidor
A OWASP recomenda conceder apenas as permissões necessárias para o trabalho de uma pessoa e validar que as restrições pretendidas se mantenham. Aplique esse princípio ao plano de hospedagem: use identidades individuais, credenciais de aplicação específicas do projeto e um caminho de implantação documentado. Um diretório com o nome de um cliente é um auxílio organizacional, não uma política de acesso.
Se usar Docker, trate o acesso ao seu daemon como uma responsabilidade de nível de host. A documentação de segurança do Docker explica que um operador de daemon confiável pode montar e modificar arquivos do host. Dar a um contratado externo controle irrestrito do Docker é, portanto, uma má combinação para um host que contém dados de um cliente não relacionado.
Instâncias VPS separadas permitem administração de sistema operacional e decisões de lançamento separadas. Elas ainda exigem permissões cuidadosas dentro de cada projeto. Credenciais comuns da agência ou uma conta de implantação compartilhada podem reconectar os riscos que você pretendia separar.
Trabalhe com dois briefings fictícios de clientes
Os clientes abaixo são exemplos fictícios, não históricos de clientes. A agência opera ambos os projetos hoje, mas seus requisitos de acesso e prazos diferem.
Colocar esses dois projetos juntos tornaria o acesso de contratados e o cronograma de lançamento da Morrow parte do risco operacional da Aster. A decisão de servidores separados segue essas restrições; ela não afirma que a Morrow precisa de um número específico de CPUs nem que a Aster está livre de riscos.
Role horizontalmente para ver todas as colunas da tabela.
| Fator de decisão | Aster Furniture: site de folheto | Morrow Workshops: site de registro |
|---|---|---|
| Carga de trabalho | Páginas públicas e atualizações ocasionais de conteúdo | Formulários, um banco de dados e exportações agendadas de registro |
| Acesso | O cliente edita o conteúdo; a agência implanta | Desenvolvedor externo precisa de administração do host |
| Manutenção | Uma janela noturna acordada | Sem alterações planejadas durante um lançamento de reservas |
| Impacto de incidente | Uma indisponibilidade temporária da página pode ser discutida | Envios perdidos ou duplicados exigem investigação |
| Requisito de saída | Exportar conteúdo e mover a aplicação | Transferir um ambiente operado independentemente |
| Decisão provisória | Considerar compartilhar com sites compatíveis operados pela agência | Usar um VPS separado e credenciais de projeto separadas |
Compare o custo total dos dois arranjos
Construa duas versões de orçamento usando o configurador atual: uma configuração compartilhada e uma configuração por projeto. Para cada uma, liste o total de hospedagem para o período selecionado, opções recorrentes, serviços externos e tempo de manutenção da agência separadamente. Evite copiar um preço antigo para o briefing do cliente. Registre quando a configuração foi preparada e quem aprovou a alocação.
Para um host compartilhado, acorde como os clientes dividem os custos fixos e o que acontece quando um sai ou requer uma atualização. Partes iguais são simples, mas podem ser inadequadas quando um projeto causa a maior parte do crescimento de armazenamento ou do trabalho operacional. Servidores separados tornam a atribuição mais clara, enquanto adicionam tarefas separadas de patch, monitoramento e recuperação.
Deixe folga de recursos para lançamentos, backups e trabalhos temporários. Contêineres Docker não têm restrições de CPU ou memória por padrão; configure limites apropriados e avalie a carga de trabalho combinada. Uma lista de contêineres sozinha não demonstra um orçamento de recursos viável.
Torne manutenção e recuperação específicas do projeto
Em um host compartilhado, uma reinicialização do sistema operacional afeta todos os projetos residentes. Coloque a manutenção do host em um calendário comum e identifique quem contata cada cliente. Mantenha os lançamentos de aplicações separados onde for prático, e evite agendar a exportação de dados de um projeto durante o lançamento importante de outro.
As notas de recuperação devem identificar o banco de dados, arquivos, configuração e credenciais necessárias de um projeto sem copiar segredos para as notas. Planeje a restauração para um destino de teste separado. Restaurar um host compartilhado inteiro como primeira resposta poderia substituir alterações saudáveis pertencentes ao outro cliente.
Com instâncias VPS separadas, registre os serviços compartilhados que permanecem. Uma conta de DNS comum, destino de backup ou operador ainda pode afetar ambos os projetos. A separação de servidores não é evidência de infraestrutura física independente ou disponibilidade garantida.
Valide o arranjo e defina gatilhos de revisão
Antes de aceitar o acordo, peça a um segundo operador que verifique se uma identidade de projeto pode realizar seu trabalho atribuído e não pode ler os arquivos, backups ou segredos do outro projeto. Revise as permissões de banco de dados e credenciais implantadas, assim como as telas da aplicação. Use dados de teste inofensivos em um ambiente acordado; não investigue os dados de produção de outro cliente.
Registre o resultado como aceito, rejeitado ou aguardando uma correção nomeada. Se o isolamento não puder ser demonstrado, restrinja o acesso ou mova o projeto antes de conceder permissões mais amplas. Uma resposta bem-sucedida da homepage não é uma verificação de acesso ou recuperação.
- Mantenha um registro de decisão com o layout escolhido, alocação de custos aprovada, responsáveis e itens não resolvidos.
- Revise a escolha quando um administrador externo se juntar, uma janela de lançamento mudar, o armazenamento crescer ou um cliente se preparar para sair.
- Use o guia de responsabilidades para transformar a escolha técnica em um acordo operacional.
Fontes e revisão
As referências técnicas foram verificadas em setembro de 12, 2026. Os exemplos são exercícios de planejamento; a documentação de software referenciada não estabelece capacidades de serviço PrivateHostLab.