Vários sites no mesmo servidor

Um único servidor pode hospedar tantos sites e apps web quanto a RAM e o disco permitirem. A regra para saber se um novo deploy fica ao lado de um existente ou se substitui o anterior é a mesma em todos os fluxos: depende do identificador que você informa.

A regra

O identificador é o que prende um deploy a um slot no servidor:

• Site estático → o identificador é o domínio que você digitou durante o deploy.
• App web → o identificador é o nome do app na seção Avançado (por padrão, é o nome da sua pasta, por exemplo my-api).
• Banco de dados → o identificador é o nome do banco + o mecanismo (cada mecanismo — Postgres / MySQL / MariaDB — roda no próprio contêiner).

Sites estáticos — identificados pelo domínio

Cada deploy de site estático fica em /var/www/<domain>/ e ganha seu próprio bloco no Caddyfile:

mysite.example.com { root * /var/www/mysite.example.com; file_server }
api-docs.example.com { root * /var/www/api-docs.example.com; file_server }

Dois domínios diferentes = duas pastas diferentes, dois blocos no Caddyfile, ambos servindo em paralelo. O Caddy cuida dos certificados HTTPS de cada um de forma independente.

Se você fizer um novo deploy para o mesmo domínio, Faro narra no chat a etapa que está prestes a substituir os arquivos:

*"Atenção: /var/www/mysite.example.com/ já contém um deploy anterior. Conteúdo atual: index.html, about.html, assets/. Tudo ali será substituído pelos seus N arquivos enviados. Se você tiver um diretório de runtime (uploads/, data/ etc.) que deseja manter, cancele agora, adicione um arquivo vazio .helm-keep dentro dele pela aba Arquivos e execute o deploy novamente."*

O marcador .helm-keep é a saída de emergência — veja [Preservar uma pasta entre redeploys](#preserve-a-folder-across-redeploys) abaixo.

Apps web — identificados pelo nome do app

Cada deploy de app web fica em /opt/<appName>/ e roda como sua própria unidade systemd:

/opt/my-api/      → my-api.service      (Node, port 3000)
/opt/scraper/     → scraper.service     (Python, port 5000)
/opt/notifier/    → notifier.service    (Go, port 8080)

Três nomes de app diferentes = três serviços independentes. Cada um tem sua própria porta interna, seu próprio usuário e seus próprios logs. O Caddy faz proxy reverso de um domínio para cada um. Custo de recursos: pequeno (Node e Python usam cerca de 50–200 MB de RSS, dependendo do app).

Se você fizer redeploy com o mesmo nome de app, o /opt/<app>/ existente é substituído e o serviço reinicia com o novo código. A mesma saída de emergência com .helm-keep se aplica.

O slot "sem domínio" é único

Se você fizer deploy de um site estático ou app web sem um domínio, ele vai para um slot especial "default":

• Estático: /var/www/default/
• App web: as mesmas regras de /opt/<appName>/ se aplicam (você ainda escolhe um nome de app)

Para sites estáticos, existe apenas um slot default. Um segundo deploy estático sem domínio substitui o primeiro, porque o identificador do slot é a string literal default. Se quiser dois sites estáticos acessíveis só por IP, você precisa dar um (sub)domínio real para pelo menos um deles.

Para apps web, o identificador pelo nome do app ainda diferencia tudo — apps web acessíveis só por IP podem coexistir sem problema, desde que tenham nomes de app diferentes, porque a porta por baixo é interna e o Caddy é quem mapeia :80 para um deles. (Na prática, só um app web sem domínio pode ser o destino "default" do Caddy na porta 80 por vez. Faro entende isso e te avisa.)

Preservar uma pasta entre redeploys

Quando você faz redeploy para o mesmo identificador, o padrão é apagar e substituir. Para manter um subdiretório específico (caso típico: dados enviados por usuários em uploads/, caches de runtime em data/), coloque um arquivo vazio chamado **.helm-keep** dentro dele antes do próximo redeploy:

1. Abra o painel de serviço do site → aba Arquivos.
2. Entre no subdiretório que você quer manter (por exemplo, uploads/).
3. Clique em + Novo arquivo na barra de ferramentas, digite .helm-keep e pressione Enter.
4. Faça o redeploy normalmente — Faro detecta o marcador, guarda esse subdiretório antes de apagar tudo e depois o restaura quando os novos arquivos chegam.

Se preferir fazer isso fora do painel, qualquer uma destas opções também funciona: arrastar e soltar um .helm-keep vazio do seu computador para a subpasta, enviá-lo por SFTP (FileZilla, Cyberduck), acessar por SSH e executar sudo touch /var/www/<domain>/<subdir>/.helm-keep, ou simplesmente pedir ao Faro no chat (*"crie um .helm-keep vazio em /var/www/mysite.example.com/uploads/"*).

Faro narra isso no chat antes da etapa destrutiva, listando os diretórios mantidos para você confirmar:

*"Preservando estes diretórios porque eles têm um marcador .helm-keep dentro: uploads/, data/. Todo o resto será substituído pelos seus N arquivos enviados."*

Se o novo envio também contiver um diretório uploads/, a versão preservada no servidor prevalece — Faro avisa depois que o uploads/ do seu envio foi descartado. Para fazer com que a versão enviada prevaleça, remova o marcador .helm-keep e faça o redeploy.

Limites de recursos

Não existe um limite fixo de quantos sites você pode rodar — isso é determinado pela RAM e pelo disco. Regras gerais em um servidor pequeno (2 GB de RAM):

• Sites estáticos praticamente não consomem recursos — são arquivos em disco + um bloco no Caddy. Dá para rodar facilmente mais de 50. O limitador é o disco, e cada um costuma ser bem pequeno (≤ 100 MB).
• Apps web nativos custam cerca de 50–200 MB de RSS cada, dependendo da linguagem e do que fazem. Uma máquina de 2 GB roda com folga de 5 a 8 deles junto com o Caddy + um banco de dados.
• Apps web em contêiner adicionam cerca de 30–100 MB por contêiner além do custo do runtime — fixam versões de runtime, mas consomem mais RAM. Veja [Nativo vs. contêiner](#) para entender a diferença.
• Bancos de dados são os mais pesados — Postgres ou MySQL ocioso usa cerca de 100–300 MB; sob carga, o pool de buffers pode crescer até um limite configurável.

A aba Status em cada painel de serviço mostra a memória + CPU atuais; o painel do servidor vai (em uma versão futura) mostrar o total consolidado de tudo que roda na máquina.