O que é o Dify
O Dify é uma plataforma de código aberto para criar aplicações com LLMs. Oferece um canvas visual de workflows, um pipeline de RAG da ingestão à recuperação, agentes com ferramentas do seu marketplace, de servidores MCP ou de APIs personalizadas, uma IDE de prompts, APIs de backend como serviço e integrações com ferramentas de observabilidade como Langfuse, Opik e Arize Phoenix. Você pode usar o Dify Cloud, hospedar por conta própria a Community Edition com Docker Compose ou consultar o Dify Enterprise, que acrescenta SSO, RBAC e SLAs de suporte. O nó Code executa Python ou JavaScript em um sandbox, e o nó Human Input pausa um workflow para que uma pessoa responda.
Construtor de apps versus plataforma de agentes governada
O Dify e o EDDI se sobrepõem em RAG, ferramentas e agentes, mas otimizam para pessoas diferentes. O Dify otimiza para quem quer montar aplicações visualmente e entregá-las rápido, com um nó de código como válvula de escape. O EDDI otimiza para operadores que precisam que o comportamento do agente seja uma configuração declarativa e revisável, com governança ao redor. Muitas equipes começam no Dify, com razão, e algumas migram quando surgem requisitos de multi-tenancy, de licenciamento ou de auditoria.
Conveniência do construtor versus superfície de operação
| Dimensão | Dify | EDDI |
|---|---|---|
| Abstração principal | Canvas visual de workflow e chatflow, com uma IDE de prompts | Config-as-code: recursos JSON criados no Manager ou na API, versionados como código-fonte |
| Licença | Dify Open Source License: Apache 2.0 mais condições. A operação multi-tenant do código-fonte exige autorização por escrito, e o logotipo e o copyright do frontend devem ser mantidos | Apache 2.0, aprovada pela OSI |
| Lógica personalizada | O nó Code executa Python ou JavaScript em um sandbox que bloqueia o sistema de arquivos, a rede de saída e comandos do sistema, com um conjunto fixo de pacotes | Sem avaliação de código em tempo de execução; a lógica é declarada ou fica atrás de uma ferramenta MCP ou de uma chamada HTTP |
| Human in the loop | O nó Human Input pausa um workflow para um formulário respondido no app web ou por e-mail; espera padrão de 3 dias, depois um ramo de timeout | Pontos de aprovação em turnos, chamadas de ferramentas e fases de grupo; as políticas de timeout incluem WAIT_INDEFINITELY, AUTO_APPROVE, AUTO_REJECT e ABORT; aprovações no Manager e no Slack |
| Ferramentas e integrações | Marketplace, servidores MCP e APIs personalizadas | 84 ferramentas MCP, um cliente MCP, importação OpenAPI, httpCall, A2A |
| RAG | Pipeline de conhecimento integrado com extração de documentos | 8 provedores de embeddings, 6 vector stores, além de RAG via httpCall sem infraestrutura |
| Multiagente | Agentes e nós de workflow compostos no canvas | Discussões em grupo com 7 estilos, decisões e divergências registradas, aprovação humana opcional por fase |
| Identidade e acesso | Workspaces; SSO e RBAC por meio do Dify Enterprise | Keycloak/OIDC opcional com os papéis eddi-admin e eddi-approver na versão de código aberto |
| Observabilidade e auditoria | Logs e monitoramento, integrações com Langfuse, Opik e Arize Phoenix | Métricas Prometheus e um ledger de auditoria assinado com HMAC, somente de acréscimo e com verificação de sequência |
| Implantação | Dify Cloud, Docker Compose, Enterprise sob consulta | Docker, Helm, Kustomize, OpenShift (imagem certificada pela Red Hat, Operator via OperatorHub) |
Os detalhes sobre a outra ferramenta foram conferidos na documentação oficial e no repositório dela em outubro de 2026. Esses projetos mudam rápido, então confirme o comportamento atual com o fornecedor antes de decidir.
Como escolher entre os dois
Onde o Dify é a melhor escolha
- Você quer um canvas visual que quem não é engenheiro consiga ler e estender, com retorno rápido durante a construção.
- Um marketplace de plugins e templates de workflow prontos economizam tempo real de integração.
- Você quer uma opção hospedada (Dify Cloud) e não quer operar nada por conta própria.
- Um nó Code é um recurso que você quer: pequenas transformações de dados em Python ou JavaScript dentro do workflow.
- Você mantém uma única implantação interna para a sua própria equipe, então a condição de licença sobre multi-tenancy não se aplica a você.
Onde o EDDI é a melhor escolha
- Seu jurídico precisa de uma licença Apache 2.0 simples, inclusive para atender muitos tenants ou clientes a partir de uma implantação.
- A revisão de segurança proíbe a execução de código dentro da plataforma de automação, com ou sem sandbox.
- Chamadas de ferramentas ou fases de grupo específicas precisam de uma decisão humana, registrada em um ledger assinado.
- O comportamento do agente precisa ser versionado, comparado por diff e promovido entre ambientes como configuração.
- Você precisa de implantação em Kubernetes, OpenShift ou isolada da internet (air-gapped) com modelos locais.
Migrando um app do Dify
Os apps do Dify são grafos visuais e os agentes do EDDI são configuração, então isto é uma tradução, não uma importação. O que exige mais reflexão são os nós Code, que viram configuração ou uma ferramenta declarada.
| Dify | EDDI |
|---|---|
| Chatflow ou workflow | Agente EDDI: pipeline mais regras de comportamento |
| Nó LLM e prompt | Tarefa de LLM com uma mensagem de sistema e snippets de prompt versionados |
| Base de conhecimento | Base de conhecimento RAG do EDDI com um provedor de embeddings e uma vector store |
| Ferramenta, plugin ou servidor MCP | Conexão de cliente MCP, httpCall ou uma API importada via OpenAPI |
| Nó Code | Regras de comportamento e lógica de prompt, ou uma ferramenta MCP se precisar de código de verdade |
| Nó Human Input | Regra PAUSE_CONVERSATION ou toolApprovals, com uma política de timeout |
| Chaves de API dos provedores | Entradas do Secrets Vault, referenciadas como ${vault:key} |
Perguntas frequentes
O Dify é de código aberto?
O Dify publica o código-fonte sob a Dify Open Source License, que é a Apache 2.0 com condições adicionais: não é permitido usar o código-fonte para operar um ambiente multi-tenant sem autorização por escrito, nem remover o logotipo ou as informações de copyright do frontend. Isso não é a Apache 2.0 simples que o EDDI usa, então leia a licença com o seu jurídico se alguma das condições puder se aplicar.
O EDDI tem um construtor visual como o Dify?
O EDDI Manager é uma interface React de produção para criar, implantar e monitorar agentes, disponível em 11 idiomas. É uma interface de gestão, não um canvas de nós: você configura agentes, prompts, ferramentas e pipelines, e cada alteração é um recurso versionado, não um diagrama.
Por que o EDDI evita um nó de código?
Um nó de código em sandbox é um recurso razoável, e o Dify restringe o que ele pode acessar. Mas qualquer execução de código dentro da plataforma é uma superfície de ataque que uma revisão de segurança precisa examinar. O EDDI mantém o comportamento do agente declarativo, de modo que o que uma ferramenta pode fazer é o que você declara e aprova.
Podemos usar o Dify e o EDDI juntos?
Sim. O Dify pode usar servidores MCP e APIs personalizadas, e o EDDI expõe um servidor MCP e uma API REST, então um workflow do Dify pode chamar um agente do EDDI como uma etapa governada. O EDDI pode chamar a API do Dify por meio de httpCall.
Outras comparações
- EDDI vs. LangChain e LangGraph
- EDDI vs. Microsoft Agent Framework (AutoGen e Semantic Kernel)
- EDDI vs. CrewAI
- EDDI vs. n8n
- EDDI vs. Flowise
- EDDI vs. Rasa
- Todas as alternativas: construtores, bibliotecas e plataformas em nuvem
Pronto para produção?
Obtenha implantação gerenciada, suporte com SLA e ajuda prática da equipe que desenvolve o EDDI.
Fale conosco sobre implantação enterprise