Operion

Operion runs workflows. A workflow is a graph of nodes: a trigger starts an execution, and each node's output port decides which nodes run next. A node can call an HTTP API, transform data, branch, wait for days, or hand the work to a service of your own.

It is built for a platform that serves many companies. The platform registers the events its systems publish, such as "employee created", in an event catalog, and each company (a tenant) builds its own workflows on those events. A tenant only ever sees and starts its own workflows.

How it runs

• One binary. operion serve runs the HTTP API, the webhooks, the scheduler, the Kafka consumer and the worker in one process.
• PostgreSQL is the only state. Workflows, executions, schedules and pending work live in Postgres. Waits and retries are rows in a jobs table, so an execution survives a restart and several replicas can share the work.
• Kafka only at the edge. When you give it brokers, Operion consumes the topics that published workflows listen on. Nothing inside Operion depends on Kafka.
• Your own node types over HTTP. A node type can be a service in any language, registered with a URL. Operion signs every call, and the service can answer later through a callback.

Operion ships as a container image, ghcr.io/operion-flow/operion, that you run in your own infrastructure next to PostgreSQL.