Como hospedar vários sites em uma VPS sem virar bagunça

Você quer hospedar mais de um site, mas não quer que o seu servidor vire uma gaveta de tranqueiras: pastas misteriosas, domínios quebrados, um projeto derrubando o outro e nenhuma ideia clara de onde cada coisa está.

Esse medo é compreensível. Um único servidor consegue rodar vários sites muito bem. O truque é parar de pensar nele como “uma máquina para um site só” e começar a enxergá-lo como um pequeno prédio com várias salas separadas.

Um servidor pode ter mais de uma porta de entrada

Um servidor é apenas um computador na internet. Como o seu notebook, ele consegue rodar mais de uma coisa ao mesmo tempo. Um site pode ser um blog WordPress. Outro pode ser um pequeno web app. Outro pode ser uma ferramenta privada para a sua equipe.

Hospedar vários sites em um servidor significa que cada projeto divide a mesma casa física, mas ainda tem a sua própria porta de entrada.

A porta de entrada geralmente é um nome de domínio, como example.com, shop.example.com ou another-site.com. Os visitantes não se importam que esses nomes cheguem ao mesmo servidor. Eles digitam o endereço e o site certo aparece.

A bagunça começa quando cada projeto é tratado como um grande amontoado. Os arquivos se misturam. Os domínios apontam para o lugar errado. O HTTPS funciona para um site, mas não para outro. Arrumar um projeto quebra os outros sem querer.

Uma configuração organizada dá a cada projeto uma identidade clara: seu próprio nome, seu próprio destino, sua própria conexão segura e seu próprio lugar para existir.

Domínios são placas de sinalização, não sites

Um domínio não contém o seu site. Ele é mais parecido com uma placa na estrada.

Quando alguém visita o seu domínio, a internet verifica para onde aquele nome aponta. Esse sistema de apontamento se chama DNS, sigla de Domain Name System. O DNS é a agenda de endereços da internet. Ele liga um nome legível ao servidor que deve responder.

Se você tem três domínios em um servidor, todos os três podem apontar para o mesmo endereço do servidor. Isso é normal.

Mas apontar o domínio é só a primeira metade do trabalho. Isso leva o visitante até o prédio. Não decide em qual sala ele deve entrar.

É por isso que configurar o domínio e cuidar do roteamento no servidor são duas tarefas diferentes. O DNS diz: “Vá para este servidor”. O roteamento diz: “Para este domínio, mostre este projeto”.

Se você quer o lado do domínio explicado em termos para iniciantes, este guia é um bom complemento: Como apontar um domínio para o seu servidor.

O roteamento é o recepcionista na entrada

Assim que um visitante chega ao seu servidor, algo precisa ler o domínio que ele pediu e mandá-lo para o projeto certo.

Esse “algo” costuma ser chamado de servidor web ou proxy reverso. Um proxy reverso é um diretor de tráfego. Ele fica na entrada, olha o domínio solicitado e encaminha o visitante para o site ou app correto nos bastidores.

Pense nele como o recepcionista de um prédio comercial.

Alguém entra e diz: “Vim para o estúdio de design”. O recepcionista o manda para a sala 201. Outra pessoa diz: “Vim para o contador”. Ela vai para a sala 304. Mesmo prédio, destinos diferentes.

No seu servidor, example.com pode ser roteado para um site de marketing. app.example.com pode ser roteado para um web app. blog.example.com pode ser roteado para o WordPress.

Um bom roteamento mantém o endereço público simples enquanto deixa cada projeto funcionar do seu jeito. Um site pode ser feito de páginas estáticas. Outro pode usar um banco de dados. Outro pode rodar como um serviço de aplicação. Os visitantes não veem essa complexidade. Eles só veem o site correto.

Se você está publicando um app em vez de um site clássico, a ideia é a mesma. O app precisa de um lugar para rodar e o domínio precisa rotear para ele. Cobrimos esse caminho em Como publicar um pequeno web app sem DevOps.

HTTPS é um cadeado para cada endereço

HTTPS é a versão segura da conexão com um site. É o que dá aos visitantes o ícone do cadeado no navegador e protege o tráfego entre eles e o seu site.

Quando você hospeda vários sites, normalmente precisa de HTTPS para cada domínio ou subdomínio. O cadeado pertence ao endereço que as pessoas visitam, não apenas ao servidor como um todo.

Isso significa que example.com, shop.example.com e another-site.com precisam, cada um, estar devidamente protegidos.

Sem isso, os visitantes podem ver avisos assustadores no navegador. Ou um domínio pode acabar mostrando, por engano, um certificado destinado a outro. Isso passa uma impressão nada profissional e, quando se trata de formulários, logins, lojas ou páginas de administração, não é opcional.

A boa notícia é que o HTTPS não precisa ser caro nem misterioso. Certificados gratuitos são comuns e podem se renovar automaticamente quando a configuração está limpa. A parte importante é garantir que cada site tenha o seu próprio caminho seguro do navegador até o projeto correto.

Para uma explicação em linguagem simples, veja Como conseguir HTTPS gratuito no seu próprio servidor.

Mantenha os projetos em salas separadas

Compartilhar um servidor não deveria significar compartilhar tudo.

Cada site ou app deveria ter o seu próprio espaço. No mínimo, isso significa que você sabe quais arquivos, domínio, banco de dados e serviços em segundo plano pertencem a qual projeto. Se um site precisar ser removido mais tarde, você não deveria ter que fazer arqueologia.

A separação também reduz acidentes. Se você atualiza um projeto, os outros não deveriam se importar. Se um app enche a sua pasta de uploads, ele não deveria engolir em silêncio o servidor inteiro. Se um site tem um problema, você deveria conseguir raciocinar sobre ele sem abrir todas as gavetas da casa.

Existem diferentes formas de criar essa separação. Algumas pessoas usam pastas e usuários separados. Outras usam contêineres, que são como marmitas etiquetadas para os apps e seus ingredientes. Outras usam uma combinação.

O método exato importa menos do que o resultado: cada projeto tem um limite.

Você também deveria pensar nos backups. Quando você hospeda vários projetos em um servidor, um único erro grave pode afetar mais de um site. Um backup útil não é só “alguns arquivos em algum lugar”. É algo que você consegue de fato restaurar. Se você ainda não planejou isso, leia Como fazer backup do seu servidor — e realmente conseguir restaurá-lo.

O atalho

Tudo o que está acima dá para fazer na mão. O problema é que só continua viável enquanto você ainda lembra como conectou tudo — qual domínio aponta para onde, qual site recebeu qual certificado, qual pasta pertence a qual projeto. Três sites e alguns meses depois, essa memória é a primeira coisa a sumir, e normalmente é aí que uma pequena mudança quebra outra coisa sem fazer alarde.

O Server Manager foi feito para carregar esses detalhes por você. Quando você adiciona um site, ele dá ao projeto seu próprio lugar para existir, faz o domínio certo apontar para ele e emite HTTPS para aquele endereço exato — o roteamento e os certificados por site que as seções acima percorreram, resolvidos em uma única passada em vez de vários passos delicados, e renovados sozinhos para que um cadeado nunca expire em silêncio. Cada projeto mantém o seu próprio limite, então atualizar ou remover um não mexe nos outros, e um site que enche o seu disco ou que sai do ar continua sendo problema daquele site só.

O verdadeiro benefício é que tudo continua legível. Meses depois você pode abrir e ver num relance qual site responde a qual domínio e se cada um está seguro, em vez de ler arquivos de configuração e ficar chutando. Você tem o resultado que queria no começo — vários sites em um servidor, cada um atrás da sua própria porta de entrada — sem se tornar a pessoa que precisa lembrar de cada detalhe escondido para manter tudo de pé.

A sua vitória: um servidor, vários sites organizados

Você não precisa de um servidor separado para cada sitezinho ou app. Você precisa de rótulos claros, rotas limpas, endereços seguros e uma separação sensata.

Quando essas peças estão no lugar, um servidor pode parecer tranquilo em vez de lotado. Cada projeto tem a sua porta. Os visitantes chegam onde deveriam. O HTTPS funciona onde deveria. E quando você volta meses depois, a configuração ainda faz sentido.