Server Manager/ Help
Open Server Manager →

Nativo vs. Contêiner — qual devo escolher?

Nativo executa seu app web diretamente no servidor pelo systemd — rápido, pouca RAM, ambiente de execução compartilhado. Contêiner executa o app dentro do Docker — versão própria do ambiente de execução por app, ~30–100 MB a mais de RAM.

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

O botão de alternância "Implantar como" dentro da seção Avançado da janela de implantação
O botão de alternância "Implantar como" dentro da seção Avançado da janela de implantação
  • 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.

Implantação nativa — três apps no systemd, todos compartilhando uma instalação de Node e uma de Python no servidor
Implantação nativa — três apps no systemd, todos compartilhando uma instalação de Node e uma de Python 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.

Implantação em contêiner — três apps, cada um em seu próprio contêiner Docker com sua própria versão fixa do ambiente de execução
Implantação em contêiner — três apps, cada um em seu próprio contêiner Docker com sua própria versão fixa do ambiente de execução
  • Arquivos em /opt/<appName>/ — seu código-fonte, mais um Dockerfile e um docker-compose.yml que nós geramos
  • Serviço gerenciado pelo Docker — sudo docker compose -f /opt/<appName>/docker-compose.yml ps mostra 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.13 podem 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õesNativo
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 depoisContê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:

  1. Abra AçõesImplantar do meu computador (ou Implantar um app web de um repositório git)
  2. Solte seu código ou cole a URL do repositório
  3. Expanda Avançado → alterne o botão Implantar como
  4. 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.