`runner destroy`

Remove os containers de uma instância e os arquivos de rota do Traefik dela. Irreversível: não há undo, e as rotas são o que mais dá trabalho reconstruir.

runner destroy <PROJECT> --instance <INSTANCE> [--force]
Flag Default Descrição
-i, --instance Nome da instância (obrigatório)
-y, --force false Executa. Sem ela, o comando faz dry-run (alias: --yes)

Sem `--force`, é dry-run

O comando mostra exatamente o que removeria e não toca em nada:

$ runner destroy nfse --instance production
DRY-RUN — destroy nfse/production removeria:

  containers (1):
    - nfse_production_v2-5-1
  arquivo(s) de rota do Traefik: 1

Nada foi removido. Para executar: --force

Confira a lista antes de repetir com --force. Se ela trouxer algo que você não reconhece, não execute — abra um issue.

Alcança só o app nomeado, não a família

destroy nfse remove os containers do app nfse. Não toca em nfse-front nem em nfse-agent: são apps distintos, com project: próprio.

Para derrubar a família inteira, rode o comando uma vez por app — de propósito. Não existe destroy --all, e não deve existir: enquanto deploy --all tem uso legítimo (rollout geral), o análogo aqui é só o desastre.

Trava de raio

Se a lista de containers trouxer qualquer nome que não case com {project}_{instance}_, o comando aborta sem remover nada e nomeia o intruso:

destroy_abortado: 2 container(s) da lista NÃO pertencem a 'nfse/production':
["hogi_production_v2-1-0", "ccs_sys_production_v2-95-3"]

Nada foi removido. Isto é uma trava de raio: um destroy que alcança outro
projeto é sempre erro, nunca intenção.

A trava é defesa em profundidade. O recorte por app já acontece na listagem — ela existe porque um comando que remove não pode depender de a listagem estar certa.

Histórico. Até a v2.79.0 o filtro de containers ignorava o nome do projeto e devolvia a frota inteira do servidor: destroy de um app removia containers de todos os projetos. Corrigido na v2.80.0, junto com a trava e o dry-run. Se você opera um runner em versão anterior, não use destroy em servidor compartilhado.

Ordem das operações

As rotas do Traefik saem antes dos containers, de propósito: uma falha no roteamento aborta a operação com os containers ainda de pé, que é o estado mais fácil de recuperar.

Ver também

By Borlot.com.br on 19/08/2026