Olá pessoALL, no artigo de hoje quero falar de um assunto que apareceu em praticamente toda conversa sobre automação e agentes de IA no último ano: o N8N. E quero falar dele sem torcer o nariz, porque a ferramenta é boa. Mas quero te provocar com uma pergunta que poucos param para fazer: se você (ou seu cliente) já está dentro do ecossistema Microsoft, será que vale a pena subir e manter mais uma peça de infraestrutura?

Durante os últimos meses, parece que todo mundo na comunidade de IA descobriu o N8N ao mesmo tempo. Vídeo no YouTube, thread no X, post no LinkedIn, sempre o mesmo fluxo colorido conectando um webhook a um modelo de linguagem e mandando o resultado pro Slack. E olha, faz sentido o hype. O N8N é open source, tem centenas de integrações prontas e te dá aquela sensação gostosa de montar um fluxo arrastando caixinhas. Para quem está fora da nuvem das grandes ou quer self-hosting puro, é uma excelente escolha.

Mas é exatamente aí que mora a pergunta que ninguém faz.

O que o hype não te conta sobre self-hosting

O N8N "gratuito" é o N8N que você mesmo hospeda. E self-hosting nunca é só apertar um botão. Conversando com alguns times que adotaram a ferramenta na empolgação, a história costuma ser parecida: subiram um container, funcionou lindamente na demo, e três semanas depois estavam discutindo backup do banco, certificado SSL expirando, fila de execução travando sob carga e quem ia ficar de plantão quando o fluxo de produção caísse de madrugada.

Vamos colocar números nisso, porque número é o que importa na hora de assinar a fatura.

Para rodar N8N self-hosted de forma minimamente séria, você precisa de:

• Uma VM ou container rodando 24 horas por dia, mesmo que seus fluxos executem 5 minutos no dia inteiro.
• Um banco de dados (PostgreSQL) para persistir as execuções.
• Alguém cuidando de patches, atualizações de versão, escala e monitoramento.

Uma VM pequena no Azure tipo B2s custa, dependendo da região, algo em torno de US$30 a US$40 por mês. Some o banco gerenciado, e você passa fácil de US$70/mês, pagando o tempo todo, executando ou não. Sem contar o custo invisível, que é o mais caro de todos: o tempo do seu time mantendo aquilo de pé.

Funciona? Funciona. Mas vamos ser honestos: você acabou de transformar uma "ferramenta gratuita" num projeto de infraestrutura com dono, plantão e fatura mensal fixa.

A peça que você provavelmente já está pagando: Logic Apps

Se você está no Azure, existe uma engine de workflow que faz essencialmente o mesmo que o N8N (gatilhos, ações, conectores, retry, histórico de execução), só que você não gerencia nada da infraestrutura: o Azure Logic Apps.

E aqui entra a primeira diferença que muda o jogo: o modelo de cobrança.

No Logic Apps Consumption, você paga por execução de ação, na casa de frações de centavo. Não tem VM ligada de madrugada queimando dinheiro à toa. Fluxo não rodou? Você não pagou. Além disso, o plano Consumption ainda vem com uma cota inicial de ações gratuitas por mês, o que na prática significa que muitos fluxos de automação de PME rodam praticamente de graça.

Ou seja, compare maçãs com maçãs:

Quando você bota tudo na balança, o N8N self-hosted deixa de ser "grátis" e o Logic Apps deixa de ser "caro". Para quem já tem subscription Azure, o Logic Apps entrega o mesmo resultado com menos custo e, principalmente, sem mais uma peça de infraestrutura para você ficar de babá.

Então por que tanta gente fugia do Logic Apps?

Aqui preciso fazer uma confissão, porque seria desonesto vender o Logic Apps como bala de prata sem reconhecer o seu calcanhar de Aquiles histórico.

Sim. Eu também já torci o nariz para o Logic Apps. E o motivo era sempre o mesmo: o designer visual e o JSON por baixo dele.

Para um desenvolvedor que vive no C#, no Git e em pull requests, o fluxo de trabalho do Logic Apps clássico era um desconforto. Você montava o workflow arrastando caixinhas numa tela, e o que era salvo era um arquivo JSON gigante e ilegível. Tentar revisar uma mudança num pull request daquilo era sofrimento. Fazer merge de duas alterações no mesmo fluxo? Melhor nem tentar. Versionar lógica de negócio crítica num blob JSON que ninguém consegue ler num diff sempre foi o ponto fraco que empurrava o pessoal mais "dev" de volta para soluções como o N8N, ou para escrever a automação na unha em código.

Esse, durante anos, foi o argumento mais justo a favor das alternativas: o Logic Apps tinha a engine, mas não tinha a experiência de desenvolvimento que um time de software espera.

Mas isso acabou de mudar.

O anúncio do Build que fecha a lacuna: Logic Apps em C#

No Build deste ano, a Microsoft anunciou em preview o Logic Apps Standard SDK, um pacote NuGet (Microsoft.Azure.Workflows.Sdk) que te deixa escrever workflows do Logic Apps Standard direto em C#, com tipagem forte, IntelliSense e tudo o que você já espera do seu ambiente .NET.

E vale ressaltar um ponto importante para não haver confusão: isso não é uma nova runtime. É uma nova forma de definir os workflows. O que você escreve em C# compila para a mesma definição e roda na mesma engine do Logic Apps Standard de sempre: mesmos conectores, mesmo histórico visual de execução, mesmo monitoramento. Você muda a experiência de autoria, não o motor.

Na prática, o que isso significa? Aquele calcanhar de Aquiles do JSON ilegível simplesmente deixou de existir. Agora:

• Seus workflows vivem onde o resto do seu código vive: no repositório, no controle de versão.
• Eles fazem diff como código e são revisados em pull requests normais.
• O compilador pega erros antes de você rodar qualquer coisa.
• Você usa F5, debug e o ecossistema .NET que já conhece.

Para não ficar só nas minhas palavras, veja como fica um fluxo. Em vez de arrastar caixinhas, você encadeia as operações com .Then(...), e o formato do código espelha o formato do workflow. Você lê de cima para baixo e lê o caminho de execução:

trigger
    .Then(validateOrder)
    .Then(getOrders)
    .Then(sendResponse);

Controle de fluxo também faz parte do mesmo modelo. Um if/else, por exemplo, é só mais uma ação que você encadeia, recebendo uma factory para cada ramo:

var checkTotal = WorkflowActions.BuiltIn.Control.Condition(
    expression: () => order.Total > 1000,
    trueBranch:  () => requireApproval,
    falseBranch: () => autoApprove
).WithName("CheckOrderValue");

E quando a lógica é complexa demais para uma expressão declarativa (aquela transformação que sempre te obrigava a torturar uma expressão para fazer algo que ela não foi feita para fazer), você simplesmente cai num método C# de verdade no meio do workflow:

var enrich = WorkflowActions.BuiltIn.CustomCode<string>(async (context) =>
{
    var trigger = await context.GetTriggerResults();
    var order   = await context.GetActionResults("GetOrders");
    // sua lógica, suas bibliotecas, seus tipos
    return "enriched";
}).WithName("EnrichOrder");

Esse é o "escape hatch" que mantém você em fluxo: precisou de validação, transformação ou uma chamada para a sua própria biblioteca, você escreve um método, sem sair do arquivo nem da linguagem.

O ângulo que poucos vão comentar: isso é feito sob medida para agentes de código

Tem um detalhe nesse anúncio que merece atenção, especialmente porque o N8N cresceu justamente na onda da IA.

Agentes de código (como o GitHub Copilot e afins) são simplesmente melhores escrevendo código imperativo do que JSON declarativo. E o motivo é o mesmo conjunto de proteções que ajuda você: tipagem forte e um passo de compilação fazem com que o código que o agente gera já saia sintaticamente correto. O compilador e o sistema de tipos fazem a checagem por você. Coloque testes unitários por cima e você cobre boa parte do que importa.

Pense na ironia: a comunidade adotou o N8N em peso por causa da IA, e agora a Microsoft entregou uma forma de escrever automação que é, por construção, muito mais amigável para a IA gerar e validar do que arrastar caixinhas ou montar JSON na mão.

E não é só para integração corporativa clássica. O SDK cobre tanto os fluxos de integração (conectar sistemas e mover dados) quanto os workflows agênticos, onde um agente de IA conversacional ou autônomo conduz os passos. Os dois são cidadãos de primeira classe no mesmo SDK.

Vamos ser equilibrados: quando o N8N ainda faz sentido

Não vou cair no erro de dizer que uma ferramenta é sempre melhor que a outra. Seria desonesto, e você já deve ter percebido que esse não é o tom aqui.

O N8N continua sendo uma ótima escolha se:

• Você não está no Azure nem no ecossistema Microsoft e não quer entrar.
• Você quer ou precisa de self-hosting total por questões de soberania de dados, e tem time para manter isso.
• Seu time prefere o modelo visual puro e não tem pretensão de versionar a lógica como código.

E preciso ser honesto também sobre o lado do Logic Apps: o SDK em C# está em preview. Isso traz limitações que você precisa conhecer antes de apostar nele para produção crítica:

• Conectores Service Provider ainda não são suportados.
• Schemas dinâmicos ainda não funcionam.
• Custom code suporta apenas métodos de callback: nada de lambdas inline por enquanto.
• Autenticação por Managed Identity ainda está em desenvolvimento; por ora, você usa connection keys.

Ou seja, para um piloto, uma POC ou para começar a migrar fluxos novos, é a hora perfeita de colocar a mão. Para o coração do seu sistema em produção, espere o GA ou valide cada limitação com calma.

Minha recomendação, na prática

Se eu tivesse que resumir a decisão para um cliente que já está no Azure e estava de olho no N8N por causa do hype, minha sequência seria:

1. Já tem subscription Azure? Comece testando o Logic Apps Consumption. Você provavelmente vai rodar seus fluxos por uma fração do custo de uma VM ligada o mês inteiro.
2. Time é de desenvolvedores que vivem no Git? Experimente o novo Logic Apps Standard SDK em C#. O argumento que te empurrava para fora do Logic Apps, o JSON ilegível, não existe mais.
3. Precisa de agentes de IA no fluxo? O SDK já trata workflows agênticos como cidadãos de primeira classe, e o formato em código é muito mais amigável para a IA gerar e validar.
4. Self-hosting é requisito inegociável? Aí sim, o N8N continua sendo uma escolha legítima, com a consciência de que a conta da infraestrutura e do plantão vem junto.

O ponto central é esse: o hype não deveria te fazer pagar duas vezes. Se você já investe no ecossistema Microsoft, subir e manter mais uma peça de infraestrutura para fazer algo que a plataforma já entrega gerenciado raramente é o melhor negócio. E agora, com a possibilidade de escrever tudo em C#, foi embora a última desculpa técnica que restava para o desenvolvedor torcer o nariz.

Lição aprendida: a ferramenta mais comentada nem sempre é a mais barata, e quase nunca é a que melhor se encaixa no que você já tem.

Links Úteis

Anúncio e documentação

• Write Logic Apps in C#: introducing the Logic Apps Standard SDK: o anúncio oficial do SDK no blog do Azure Integration Services
• Create Standard workflow projects with the SDK: guia passo a passo para criar workflows code-first
• Logic Apps Standard SDK class library: referência da biblioteca de classes
• Repositório e feedback do SDK no GitHub: onde reportar issues e pedir features durante o preview

Comparação e custos

• Azure Logic Apps pricing: detalhes do modelo Consumption (por execução) e Standard
• Single-tenant Logic Apps Standard vs. Consumption: quando escolher cada modelo de hospedagem

E você, já estava de olho no N8N por causa do hype ou já tinha migrado seus fluxos para o Logic Apps? Me conta nos comentários se a chegada do SDK em C# muda a sua decisão. Espero que tenham curtido!
[]s e até a próxima.