Só é relevante se você estiver implantando um app web (Node, Python, Go). Sites estáticos e WordPress não mostram essa escolha.
Ao implantar um app web, a seção Avançado na janela de implantação tem um botão de alternância: Implantar como processo nativo ou Contêiner. As duas opções colocam seu app online por trás do com HTTPS do — a diferença é como o seu código roda por baixo.
O que você está escolhendo
- Processo nativo — o Server Manager instala o ambiente de execução uma vez no servidor (Node 22 LTS, Python 3 + venv ou Go) e executa seu app diretamente pelo como um serviço próprio.
- Contêiner — o Server Manager cria uma imagem Docker para o seu app com a versão do ambiente de execução que você escolher e a executa como um contêiner na frente do Caddy do servidor.
Em ambos os casos: mesmo domínio, mesmo HTTPS, mesmo botão para puxar a versão mais recente do git, mesmo acesso ao seu código pela aba Arquivos.
Como o Nativo funciona
Seu app fica em /opt/<appName>/ e roda como uma unidade do chamada <appName>.service. O ambiente de execução (Node, Python, Go) é instalado uma vez no nível do sistema operacional e compartilhado por todos os apps web nativos no servidor.
- Arquivos em
/opt/<appName>/ - Serviço gerenciado pelo systemd —
sudo systemctl status <appName>funciona como esperado - Logs capturados pelo journald, exibidos na aba Logs
- Ambiente de execução uma instalação de Node 22, uma de Python 3 e uma de Go no servidor — todos os apps nativos as compartilham
Como o Contêiner funciona
Seu app roda dentro do próprio contêiner Docker. O arquivo compose fica em /opt/<appName>/docker-compose.yml, e o contêiner fica por trás do Caddy do servidor, que faz proxy reverso do seu domínio para a porta interna do contêiner.
- Arquivos em
/opt/<appName>/— seu código-fonte, mais umDockerfilee umdocker-compose.ymlque nós geramos - Serviço gerenciado pelo Docker —
sudo docker compose -f /opt/<appName>/docker-compose.yml psmostra o status - Logs capturados pelo Docker, exibidos na aba Logs
- Ambiente de execução cada app fixa sua própria versão —
Node 18,Node 22,Python 3.11,Python 3.13podem coexistir
Qual devo escolher?
A maioria dos apps deve começar com Nativo. Escolha Contêiner só se tiver um motivo específico.
| Se… | Escolha |
|---|---|
| Você tem um app no servidor e não se importa em fixar versões | Nativo |
| Você quer a menor sobrecarga de RAM (importante em servidores de 1 GB / 2 GB) | Nativo |
| Você quer implantações mais rápidas (sem criar imagem) | Nativo |
| Você tem dois apps com versões diferentes do ambiente de execução (por exemplo, Node 18 + Node 22) | Contêiner para pelo menos o que for exceção |
| Você quer isolamento rígido entre apps (por exemplo, um deles é código de terceiros em que você não confia totalmente) | Contêiner |
| Seu app traz uma dependência complexa que não é o ambiente de execução (versão específica do cliente Postgres, build do ImageMagick etc.) | Contêiner (tudo vai dentro da imagem) |
| Você pretende mover este app para outro servidor depois | Contêiner (a imagem é portátil; implantações nativas dependem do ambiente de execução do servidor) |
A troca, em números aproximados:
- Nativo: ~50–200 MB de RSS por app (apenas o app + interpretador). Primeira implantação: 10–30 s.
- Contêiner: ~50–200 MB de RSS para o app + ~30–100 MB de sobrecarga do Docker por contêiner. Primeira implantação: 1–3 min (criação da imagem).
Em um servidor de 2 GB que fica quase sempre ocioso, dá para rodar 5–8 apps web nativos + Caddy + um banco de dados pequeno. Com contêineres, isso cai para ~4–6.
Trocar depois
O modo é intrínseco ao app: não há um botão de alternância no painel de serviço para trocar um app Nativo para Contêiner ou vice-versa.
Para trocar, reimplante o app pelo modal e escolha a outra opção:
- Abra Ações → Implantar do meu computador (ou Implantar um app web de um repositório git)
- Solte seu código ou cole a URL do repositório
- Expanda Avançado → alterne o botão Implantar como
- Clique em Implantar — o app existente é substituído pelo novo modo
O código permanece no disco (as regras de .helm-keep de Vários sites no mesmo servidor também se aplicam a reimplantações com Contêiner). Seu domínio continua apontando para o mesmo lugar. A indisponibilidade é a duração de uma reimplantação normal — geralmente menos de um minuto.