Como hospedar o CyberChef por conta própria em 2026: acesso seguro, hospedagem sem estado e atualizações

A demonstração mais simples do CyberChef comprova que um processo está escutando na porta 80. Em produção, é preciso obter evidências mais robustas. Mesmo depois que o container for substituído, ele deve passar por este cenário: criar uma receita com várias etapas, exportá-la, processar um arquivo representativo e confirmar que o hash da saída corresponde a um valor conhecido.

O CyberChef é implantado com um objetivo claro: servir como ambiente de trabalho no navegador para codificação, decodificação, análise e criptografia. A armadilha mais comum em sua implantação é que operações grandes esgotam a memória do navegador mesmo quando o servidor está saudável. Por isso, o tratamento da URL pública e o estado persistente precisam receber a mesma atenção dada à inicialização da imagem.

Escolha a menor topologia viável para o CyberChef

Um diagrama útil do CyberChef mostra a rota pública, a porta privada 80, o limite do estado e todos os requisitos de suporte. Indique quais setas transportam credenciais e quais representam tráfego comum de usuários. A instalação padrão do CyberChef não precisa de banco de dados nem de um serviço de runtime persistente separado. Mantenha o container web substituível e coloque qualquer componente futuro de autenticação, colaboração ou armazenamento atrás de um limite documentado separadamente.

Comprove o diagrama com uma ação real: crie uma receita com várias etapas, exporte-a, processe um arquivo representativo e confirme que o hash da saída corresponde a um valor conhecido. A pressão mais provável vem da memória e da CPU do navegador para receitas grandes, e não da capacidade computacional no lado do container em uma implantação estática padrão; monitore esse caminho em vez de tratar todas as solicitações HTTP da mesma forma.

Execute a primeira instância com formato de produção

Use o container como um runtime substituível, não como a fonte da verdade.

docker run -d \
  --name cyberchef \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  ghcr.io/gchq/cyberchef:latest

Confirme o requisito local antes de expor o serviço: a compilação padrão executada no lado do cliente não precisa de banco de dados. Inspecione o usuário do container, os caminhos com permissão de escrita e o listener associado antes de expô-lo. Execute a ação completa — crie uma receita com várias etapas, exporte-a, processe um arquivo representativo e confirme que o hash da saída corresponde a um valor conhecido — e salve a referência exata da imagem que produziu o resultado.

Teste o CyberChef de fora do servidor

Publique a interface estática em uma origem HTTPS confiável. Direcione o hostname escolhido para a porta 80 do container, encaminhe o host original e o esquema HTTPS e evite publicar uma segunda origem direta.

Teste o CyberChef a partir de um cliente externo limpo. Separe falhas de entrada das limitações conhecidas da aplicação — operações grandes esgotam a memória do navegador mesmo quando o servidor está saudável. Um erro de certificado, DNS ou 502 pertence ao roteamento; uma solicitação que chega ao CyberChef e falha depois pertence ao estado da aplicação, à capacidade ou a algum requisito de suporte. O guia de TLS para domínios personalizados aborda o primeiro grupo.

Encontre todos os bytes persistentes do CyberChef

O container padrão do CyberChef não tem nenhum volume obrigatório para dados da aplicação. Ainda assim, seu conjunto de recuperação deve ser explícito: não há dados da aplicação; preserve a configuração de implantação e fixe a versão da imagem. Não crie um volume vazio apenas para fazer a implantação parecer stateful; preserve a referência exata da imagem e a configuração revisada.

Reconstrua o CyberChef em um host vazio e execute a transação de aceitação. A recuperação será bem-sucedida quando a compilação estática fixada puder ser recriada e uma receita exportada produzir a mesma saída conhecida. Qualquer banco de dados ou serviço de colaboração conectado deve seguir seu próprio plano de backup consistente com a aplicação, enquanto o container web substituível é recriado a partir do código. O guia de implantação do Git à produção descreve esse limite reproduzível.

Mantenha um checksum ou digest da imagem conhecida como boa e teste novamente após as atualizações. Para um serviço sem estado, uma reconstrução bem-sucedida é o teste de restauração; para estados externos, o runbook do CyberChef deve apontar para o responsável e o procedimento de recuperação separados.

Proteja a parte valiosa do CyberChef

Não adicione um segredo de ambiente fictício apenas para fazer o CyberChef parecer mais protegido. A preocupação real é processar material sensível em uma imagem modificada ou não confiável. Portanto, publique apenas uma imagem oficial ou compilada de forma reproduzível quando os operadores forem colar credenciais, capturas ou evidências codificadas.

Restrinja a rota pública quando necessário, verifique o digest da imagem e execute o container sem montagens do host ou privilégios de que ele não precise. Aplique limites com base na memória e na CPU do navegador para receitas grandes, e não na capacidade computacional no lado do container em uma implantação estática padrão. Os logs devem registrar falhas e tempos sem reter os dados confidenciais processados pelo CyberChef.

Diagnostique um CyberChef que parece saudável

Meça a memória e a CPU do navegador para receitas grandes, e não a capacidade computacional no lado do container em uma implantação estática padrão, enquanto executa esta transação de regressão: crie uma receita com várias etapas, exporte-a, processe um arquivo representativo e confirme que o hash da saída corresponde a um valor conhecido. Mantenha o liveness probe simples; conversões ou operações no navegador devem pertencer a uma verificação de release separada, para que uma amostra pesada não provoque um loop de reinicialização.

O risco da atualização é que as operações de receitas do CyberChef e as bibliotecas incluídas podem alterar a saída ou a compatibilidade. Por isso, a compilação fixada precisa de um teste de regressão. Execute o digest candidato ao lado da imagem atual, forneça as mesmas entradas conhecidas para ambas e compare saídas, headers e tempos. Se operações grandes esgotarem a memória do navegador mesmo quando o servidor estiver saudável, preserve a solicitação com falha e a referência da imagem antes de alterar a rota.

Transforme o smoke test do CyberChef em uma verificação de release

O registro de release do CyberChef precisa conter fatos, não apenas “parece bom”. Armazene o digest da imagem selecionada, o checksum da configuração, o hostname público e um resultado com timestamp para: criar uma receita com várias etapas, exportá-la, processar um arquivo representativo e confirmar que o hash da saída corresponde a um valor conhecido. Use dados de amostra que não sejam de produção para que a verificação possa ser executada após cada implantação.

Comprove separadamente dois eventos do ciclo de vida. A substituição de um container deve preservar a operação normal; uma recuperação limpa deve mostrar que a compilação estática fixada pode ser recriada e que uma receita exportada produz a mesma saída conhecida. Enquanto as verificações são executadas, meça a memória e a CPU do navegador para receitas grandes, e não a capacidade computacional no lado do container em uma implantação estática padrão, e mantenha o resultado como o envelope esperado para esta versão.

Teste também uma condição negada ou inválida: envie uma entrada inofensiva próxima do limite de recursos ou formato associado a este limite: operações grandes esgotam a memória do navegador mesmo quando o servidor está saudável. O CyberChef deve falhar de forma diagnosticável e não deve sobrescrever um estado saudável. Restaure a condição válida, execute novamente a amostra e anexe os logs relevantes com dados redigidos. Esses artefatos fornecem evidências concretas para uma futura decisão de rollback.

Transfira o trabalho de infraestrutura repetível para o Dockup

Para o CyberChef sem estado, a função do Dockup é restrita e útil: iniciar a imagem fixada, manter a porta 80 privada, associar a rota HTTPS e substituir o container sem inventar armazenamento. A implantação pode ter como destino a infraestrutura do Dockup ou um servidor conectado do cliente.

Conclua a configuração da aplicação: publique a interface estática em uma origem HTTPS confiável. O Dockup deve preservar as configurações de runtime do CyberChef enquanto o operador confirma este requisito local: a compilação padrão executada no lado do cliente não precisa de banco de dados. Execute esta ação de aceitação: crie uma receita com várias etapas, exporte-a, processe um arquivo representativo e confirme que o hash da saída corresponde a um valor conhecido. A autenticação opcional ou os serviços externos devem ser representados como configurações e dependências separadas para que a implantação permaneça fiel.

Perguntas frequentes

O que o CyberChef precisa para uma implantação em produção?

Direcione o container do CyberChef na porta 80 por meio de uma única origem HTTPS. A compilação padrão do CyberChef não precisa de banco de dados nem de um serviço de runtime persistente separado. Não considere o CyberChef pronto até conseguir criar uma receita com várias etapas, exportá-la, processar um arquivo representativo e confirmar que o hash da saída corresponde a um valor conhecido.

Quais dados do CyberChef devem fazer parte de um backup?

A imagem padrão do CyberChef não tem nenhum volume obrigatório para dados da aplicação. Preserve a configuração de implantação e faça backup de qualquer estado conectado separadamente; a recuperação será bem-sucedida quando a compilação estática fixada puder ser recriada e uma receita exportada produzir a mesma saída conhecida.

O CyberChef precisa de HTTPS atrás de um reverse proxy?

Use HTTPS para a origem pública do CyberChef e mantenha a porta 80 na rota interna. Aplique corretamente a configuração do CyberChef: publique a interface estática em uma origem HTTPS confiável. No CyberChef, o HTTPS protege credenciais ou conteúdo do usuário durante o trânsito e mantém consistente o comportamento do cliente sensível à origem.

Como uma atualização do CyberChef deve ser testada?

Implante a imagem candidata do CyberChef ao lado da atual e repita a transação de aceitação com uma entrada conhecida. Dê atenção especial ao fato de que as operações de receitas do CyberChef e as bibliotecas incluídas podem alterar a saída ou a compatibilidade, portanto a compilação fixada precisa de um teste de regressão. O container padrão não tem migração de dados; por isso, mantenha o digest anterior até que as verificações de saída e compatibilidade sejam aprovadas.