finds.dev← search

// the find

bytechefhq/bytechef

★ 1,007 · Java · NOASSERTION · updated Sep 2026

Open-source AI agents and workflow automation. Self-host or embed in your SaaS. Apache 2.0 alternative to n8n and Zapier.

ByteChef is a Java/Spring workflow automation platform with AI agents built in as first-class steps, positioned as an Apache-2.0 alternative to n8n/Zapier that can also be embedded as white-label iPaaS inside someone else's SaaS. It's aimed at teams who want to self-host automation/agent infrastructure rather than rent it, and at vendors who want to resell integrations under their own brand.

Durable execution is real, not just marketing copy: every task is persisted on the Atlas runtime, so a run that fails or pauses for human approval resumes from that step instead of re-running the whole workflow from the trigger. Every connector doubles as both an agent tool and an MCP tool, so you don't maintain separate tool schemas for agents vs. workflows. The fromAi() expression (`=fromAi('order_id', 'STRING', {...})`) lets you mark an existing connector field as agent-fillable in place, which is a cleaner mechanism than most frameworks' separate tool-definition boilerplate. Polyglot code steps (JS/Python/Ruby on GraalVM) give an escape hatch when the 250+ connectors and visual editor aren't enough.

The one-command Docker quick-start uses embedded H2 with no migration path to Postgres, and Postgres+pgvector is required for the knowledge base and Copilot anyway, so the easy on-ramp is a dead end for anyone actually evaluating the AI features. The CE/EE split is wide: Workflows-as-APIs, Git-native deploys, AI Copilot, SSO/SCIM, and multi-environment promotion are all EE-only, so the free tier is closer to a single-tenant visual builder than something you'd run as a team's production automation backbone. Agent Skills and Agent Evaluations are both listed as 'in development' in the feature table, so the versioned skill-bundle and eval-harness story that's implied by the README doesn't exist yet. Running user-authored JS/Python/Ruby via GraalVM inside the same JVM as the workflow engine is a reasonable design, but the README says nothing about sandboxing or resource limits for that polyglot execution, which is worth checking before anyone lets end-users author those scripts.

View on GitHub → Homepage ↗

// want more like this?

We dig through GitHub every week and send a few repos picked for what you actually care about — each with an honest take like this one.

Get finds in your inbox → Search again →