O n8n é uma ferramenta que automatiza tarefas ligando sistemas diferentes. Ele serve bem para testes rápidos, mas rodar em produção, com muito tráfego, exige bem mais: processos de trabalho separados, banco PostgreSQL, Redis para filas, armazenamento de arquivos e um plano de atualização que preserve o histórico dos fluxos.

A equipe da Fairwinds rodou o n8n na Amazon EKS, o serviço de Kubernetes da Amazon, usando o modo de fila. Nesse modo, uma instância principal guarda os fluxos e dispara os gatilhos, enquanto instâncias trabalhadoras executam as tarefas retiradas do Redis. Webhooks de produção ficaram em processadores dedicados, com endereços públicos e internos separados. Segredos e chaves de criptografia ficaram no AWS Secrets Manager e foram sincronizados para o Kubernetes pelo External Secrets Operator.

Depois de cerca de um ano, manter funções sem suporte oficial e ajustes locais ficou difícil de justificar. A equipe então migrou do chart comunitário do Helm, um pacote que descreve como instalar a aplicação, para o chart oficial do próprio n8n, que tem manutenção ativa.

Houve uma dificuldade técnica: no chart comunitário, a instância principal usava um volume por réplica, enquanto no oficial ela rodava como Deployment com um único volume compartilhado. Como o disco gp3 da AWS não pode ser conectado a várias instâncias principais em nós diferentes, uma atualização no mesmo lugar não funcionaria. A equipe então fez uma troca completa, em vez de atualização gradual.

Antes de mexer, a equipe verificou o que ficava gravado no disco da instância principal e concluiu que nada precisava ser preservado. O estado da aplicação já estava no PostgreSQL, no Redis, no S3 e no Secrets Manager, então a persistência da instância principal foi desativada no novo chart. Banco de dados, armazenamento, perfil de acesso IAM e segredos foram mantidos.

Antes da migração em produção, a equipe testou tudo em um ambiente de homologação com uma cópia restaurada do banco. Verificou se os pods estavam saudáveis, se os fluxos conhecidos executavam e se os endereços necessários respondiam, e também testou a reversão antes de mexer no tráfego real.

A lição do relato é que, quando o estado fica fora do disco da aplicação, trocar a forma de implantação fica bem mais simples. O texto original não traz uma lista de recomendações de segurança além da separação de segredos e do teste prévio em ambiente não produtivo.