Documentação / Conceitos Fundamentais / Apps & Serviços

Apps & Serviços

Uma aplicação é a configuração que você gerencia; os contêineres que ela executa são os serviços. Esta página explica a relação entre eles, as configurações de uma aplicação e o que o sh0 faz por padrão.

Aplicações e serviços

Aplicação: a configuração persistente. Sua origem, configurações, variáveis de ambiente, domínios e limites de recursos sobrevivem a cada implantação.
Serviço: um contêiner criado por uma implantação, chamado sh0-<prefixo-id-stack>-<app>-<prefixo-id-implantação>. Cada implantação cria um novo; o contêiner anterior só é parado e removido quando o novo está saudável e roteado.

Status de uma aplicação

Uma aplicação mostra um destes status:

Estado	Significado
inactive	Criada, nunca implantada.
building	Uma implantação está construindo a imagem ou iniciando o contêiner.
running	O contêiner passou na verificação de saúde e recebe tráfego.
stopped	Parada por um usuário (`sh0 stop` ou o painel).
failed	A última implantação falhou. Um contêiner de uma implantação anterior que ainda estava rodando continua servindo.

Criar uma aplicação

Em um stack, Adicionar app abre a página Implantar com o stack pré-selecionado. Uma aplicação pode vir de uma imagem Docker, um repositório Git, um arquivo enviado, um Dockerfile, um arquivo Docker Compose, um modelo de framework ou o catálogo de templates. No terminal, sh0 push envia o diretório atual e o implanta.

Configurações de uma aplicação

A aba Configurações da aplicação contém estes campos, salvos com Salvar alterações:

Campo	Descrição
Nome do aplicativo	Identificador da aplicação; também seu nome de host dentro do stack (`<nome>` e `<nome>.internal`).
URL do repositório, Branch	Para aplicações Git: o repositório e o branch a implantar.
Caminho de build, Dockerfile	Subdiretório a construir e Dockerfile a usar. Sem Dockerfile, o sh0 detecta a tecnologia e gera um.
Porta	Porta em que a aplicação escuta dentro do contêiner; o tráfego público é encaminhado para ela.
Réplicas, Ordem de arranque, Projeto	Número de contêineres, posição quando o stack inteiro é implantado e o stack ao qual a aplicação pertence.

Não há campos de comando de build nem de inicialização: quem decide é o Dockerfile. Os argumentos de build são variáveis de ambiente marcadas como build, veja Variáveis de ambiente.

Limites de recursos

Todo contêiner de aplicação tem um limite de CPU e de memória, em qualquer instalação, com ou sem licença:

Campo	Padrão	Valores permitidos
CPU	Metade dos núcleos do host, no mínimo 0,5	`cpu_limit` em milinúcleos (1000 = um núcleo), de 100 até os núcleos do host
Memória	512 MB	`memory_limit` em MB, de 64 até a memória do host

Altere-os na aba Escalonamento da aplicação, em Limites de recursos, e depois Salvar configuração. Na API, os dois valores são inteiros e 0 restaura o padrão. Uma string como "512m" é recusada com 422.

Terminal

$ curl -s -X PUT https://panel.example.com/api/v1/apps/e17d4314-ff61-485a-a509-58b3974c1eee/resources \
    -H "Authorization: Bearer $SH0_TOKEN" -H "Content-Type: application/json" \
    -d '{"cpu_limit":500,"memory_limit":256}'
{"data":{"app_id":"e17d4314-ff61-485a-a509-58b3974c1eee","autoscale_cpu_threshold":80,"autoscale_enabled":false,"autoscale_memory_threshold":80,"cooldown_seconds":300,"cpu_limit":500,"created_at":"2026-10-02 02:52:11","current_replicas":1,"id":"64433fb7-a676-4257-8c78-474d2fb961fd","last_scale_at":null,"lb_policy":"round_robin","max_replicas":1,"memory_limit":256,"min_replicas":1,"updated_at":"2026-10-02 03:04:09"}}

Os novos limites valem a partir da próxima implantação; até lá o contêiner em execução mantém os antigos. Observado em uma aplicação de teste: antes da reimplantação o contêiner ainda tinha 512 MB e 2 núcleos (host de 4 núcleos), depois 256 MB e 0,5 núcleo:

Terminal

$ docker inspect <container> --format '{{.HostConfig.Memory}} {{.HostConfig.NanoCpus}}'
536870912 2000000000
$ sh0 deploy my-api
[*] Deploying my-api...
  Deployment ID: 9b98d35b-0751-490e-88e8-f089fb0a6007
  Status:        queued
$ docker inspect <new-container> --format '{{.HostConfig.Memory}} {{.HostConfig.NanoCpus}}'
268435456 500000000

Warning

Um contêiner que excede seu limite de memória é encerrado pelo kernel (OOMKilled). Se isso acontecer durante uma implantação, ela falha na hora em vez de esperar o tempo limite da verificação de saúde. Aumente o limite ou reduza o consumo da aplicação.

Política de reinício

Todo contêiner de aplicação roda com a política do Docker unless-stopped: o Docker o reinicia após uma falha ou reinicialização do host, a menos que você o tenha parado. A política não é configurável.

Verificação de saúde na implantação

Antes de enviar tráfego a um novo contêiner, o sh0 espera até que ele esteja saudável, por até 300 segundos. A verificação é escolhida automaticamente e não tem configurações:

Se a imagem define um HEALTHCHECK do Docker, o sh0 o utiliza.
Caso contrário, para uma aplicação web, uma conexão TCP com a porta da aplicação deve ter sucesso. Não há verificação de caminho HTTP.
Um worker (sem porta) é considerado saudável depois de ficar 15 segundos rodando sem reiniciar.

Note

Um loop de falhas ou um encerramento por falta de memória faz a implantação falhar imediatamente. Quando uma implantação falha, o contêiner anterior não é parado e continua servindo o tráfego.

Stacks

Domínios e SSL