Quarkus Flow

Quarkus Flow is a lightweight, native-friendly workflow engine for Quarkus, built on the CNCF Serverless Workflow Specification. It allows you to model both classic orchestrations and Agentic AI flows using a fluent Java DSL that maps directly to the specification’s core concepts (such as states, transitions, and event filters), all with first-class CDI and Quarkus ergonomics.

Architecture Overview

Highlights

CNCF-Compliant Vocabulary: Define workflows using a fluent Java DSL that strictly adheres to the CNCF Serverless Workflow specification.
Build-Time Optimization: Compile-time discovery of workflow descriptors and automatic injection of compiled beans.
Standard Orchestration: Robust state management, retries, branching, and event routing directly within your Quarkus app.
AI First-Class Citizen: Seamless Agentic workflows integrating with LangChain4j.
Ecosystem Integration: Native messaging support via SmallRye and HTTP client support via RESTEasy Reactive.

Why Quarkus Flow?

Instead of relying on an external orchestration cluster or opaque XML/YAML scripts, Quarkus Flow brings orchestration directly into your application codebase.

Unified Developer Experience: You’re already on Quarkus. Orchestrate without leaving your stack (CDI, Dev Services, config). Developers implement and review workflows in Java, using familiar tooling and CI.
Deterministic & Observable: Typed Java flows plus unit/integration tests and Quarkus observability result in fewer production surprises. Flows are explicit code, providing traceability for audits.
Govern AI Interactions: Encode guardrails (critique/revise loops, compliance checks, Human-in-the-loop steps) as explicit workflow tasks and transitions.
Fast & Lightweight: Built for cloud environments. Quarkus native compatibility supports fast startup and low memory footprint for containerized and serverless deployments.
Avoid Vendor Lock-in: Concepts map directly to the open specification, lowering re-platforming costs and improving longevity.

Typical use cases

Service orchestration: Call multiple microservices (OpenAPI/HTTP), correlate events, and emit domain events with declarative retries and timeouts.
Agentic AI pipelines: Draft → critique → revise loops with compliance checks and HITL (Human-in-the-loop) reviews.
Event-driven processes: Wait for external signals (e.g., "review.required"), capture context, and resume automatically.
Back-office automation: Approval chains, enrichment, and notifications.

How it compares (high-level)

The landscape is rich; here’s a brief, opinionated snapshot to help positioning. This is not exhaustive—evaluate with your team’s constraints.

Project	Model & runtime	Strengths	Consider when…	Fit vs Quarkus Flow
Temporal	Code-first workflows (SDKs in several languages) with a separate Temporal Cluster.	Excellent reliability story (durable execution, retries, signals), strong developer experience for long-running workflows.	You’re fine running a dedicated Temporal cluster and adopting its programming model/SDK; language polyglot is important.	Quarkus Flow keeps everything in your Quarkus app with CDI & build-time discovery, and aligns with CNCF Workflow concepts. You avoid running a separate orchestration control plane.
Camunda 8	BPMN 2.0 (diagram-first) with Zeebe engine; separate SaaS/self-managed control plane.	Business-friendly diagrams, mature ecosystem, monitoring/ops tooling out of the box.	You want BPMN for stakeholder collaboration and can operate Zeebe/Console.	Quarkus Flow favors code-first (fluent Java) and CNCF alignment; lighter footprint inside your Quarkus services; easier to unit test alongside code.
Netflix Conductor	JSON/YAML workflow definitions; server orchestrator + workers (HTTP/GRPC).	Good for service orchestration with pluggable tasks and external workers; battle-tested at scale.	You’re comfortable with an external orchestrator and JSON/YAML modeling + worker model.	Quarkus Flow keeps models and tests in Java, integrates tightly with CDI/Quarkus, and adds agentic AI/HITL patterns while mapping to CNCF concepts.

Project

Model & runtime

Strengths

Consider when…

Fit vs Quarkus Flow

Temporal

Code-first workflows (SDKs in several languages) with a separate Temporal Cluster.

Excellent reliability story (durable execution, retries, signals), strong developer experience for long-running workflows.

You’re fine running a dedicated Temporal cluster and adopting its programming model/SDK; language polyglot is important.

Quarkus Flow keeps everything in your Quarkus app with CDI & build-time discovery, and aligns with CNCF Workflow concepts. You avoid running a separate orchestration control plane.

Camunda 8

BPMN 2.0 (diagram-first) with Zeebe engine; separate SaaS/self-managed control plane.

Business-friendly diagrams, mature ecosystem, monitoring/ops tooling out of the box.

You want BPMN for stakeholder collaboration and can operate Zeebe/Console.

Quarkus Flow favors code-first (fluent Java) and CNCF alignment; lighter footprint inside your Quarkus services; easier to unit test alongside code.

Netflix Conductor

JSON/YAML workflow definitions; server orchestrator + workers (HTTP/GRPC).

Good for service orchestration with pluggable tasks and external workers; battle-tested at scale.

You’re comfortable with an external orchestrator and JSON/YAML modeling + worker model.

Quarkus Flow keeps models and tests in Java, integrates tightly with CDI/Quarkus, and adds agentic AI/HITL patterns while mapping to CNCF concepts.

Nothing stops you from a hybrid approach:

Use Quarkus Flow for in-service workflows, developer-centric testing, and agentic AI/HITL loops tightly coupled to your Quarkus modules.
Use a centralized orchestrator (Temporal/Camunda/Conductor) for enterprise-wide, cross-language processes or when you need their managed ops and dashboards.