Rill Flow: A Java Workflow Orchestration Engine for Distributed Systems and LLM Pipelines

What Rill Flow Solves and Who Needs It

Distributed systems frequently require orchestrating tasks across multiple services: an LLM API call that feeds into a data transformation step that feeds into a storage operation. Writing custom scheduling and retry logic for each pipeline is repetitive and error-prone. Workflow engines handle the coordination so that each service only needs to do its own work.

Rill Flow provides that coordination layer. Teams define workflows as directed acyclic graphs (DAGs) in YAML, and Rill Flow handles task dispatch, dependency tracking, parallel execution, and failure handling. The visual flow editor lets non-developers inspect and modify pipeline definitions without editing YAML directly.

The system comes from Weibo, the Chinese microblogging platform, which has used it internally for high-volume task processing. The README claims support for tens of millions of tasks per day with task execution latency under 100 milliseconds. A live demo is available at rill-flow.cloud with sandbox/sandbox credentials. The last push to the repository was on 2026-04-13. The license is Apache-2.0.

DAG Definitions, Task Execution, and the YAML Schema

Each workflow in Rill Flow is defined as a YAML document with a version, workspace, DAG name, alias, type, input schema, and task list. A task in the list specifies its category (function for HTTP service calls), a name, a resource URL pointing to the service endpoint, an execution pattern (task_sync for synchronous), tolerance for failure, the next task in the chain, and input mappings that bind context values to task inputs.

The input mapping uses JSONPath expressions: source: "$.context.Bob" means read the Bob field from the execution context; target: "$.input.Bob" means pass it as the Bob input to the task. This gives flows typed data passing without a separate schema language.

Flow definitions are submitted through the admin UI. The README walk-through covers opening the Flow Definition List, clicking Create, importing a YAML definition through the one-click import toggle, and submitting. After submission, the Test button starts an execution run with the required input parameters. The execution details page shows status and results in real time.

Deploying Rill Flow with Docker Compose

The deployment path uses Docker and Docker Compose. The docker/ directory inside the repository contains the compose configuration:

git clone https://github.com/weibocom/rill-flow.git

cd rill-flow/docker
docker-compose up -d

Once the containers are running, the Rill Flow admin interface is accessible at http://localhost with the default credentials admin/admin. On a remote server, replace localhost with the server IP; the web UI defaults to port 80.

The docker-compose.yml starts at least four services: the Rill Flow application, MySQL (port 3306), Redis (port 6379), and Jaeger for distributed tracing (port 16686 for the Jaeger UI). To verify the deployment status:

docker-compose ps

The expected output shows all four services in the Up state with their respective ports bound. The README notes that if Docker Compose V2 is installed rather than V1, use docker compose (with a space) instead of docker-compose.

The README points to a live demo at rill-flow.cloud for teams that want to evaluate the interface without a local deployment first.

LLM Service Integration and Plugin Architecture

The README lists AIGC support as a core feature, framing it as the ability to integrate LLM model services rapidly. In practice, this means an LLM API endpoint (OpenAI-compatible, Anthropic, or similar) can be registered as a task resource and called within a DAG flow the same way any HTTP service is called, with input mappings passing prompt text and receiving generated output.

The rill-flow-plugins/ directory in the repository structure suggests a plugin system for extending task types beyond the default HTTP function category. The repository layout also includes rill-flow-trigger/, which handles flow initiation from external events.

Cloud-native deployment is listed as a feature. The README mentions container deployment and function orchestration as supported, which implies the system can run on Kubernetes alongside a cloud function infrastructure rather than requiring a dedicated VM or bare-metal server.

The visual flow editor is part of the rill-flow-ui/ component. The README describes it as supporting visual process orchestration, meaning users can construct and edit DAG flows graphically rather than only through YAML import.

Limitations and Cases Where Rill Flow Is the Wrong Fit

The repository has no GitHub releases, which means there is no semantic versioned artifact. Teams that need reproducible production deployments pinned to a tested version will need to pin to a specific commit hash rather than a release tag.

The last push was on 2026-04-13, approximately five and a half months before the date of this article. The repository is not archived, but development activity is not visible from the commit history alone.

Rill Flow is Java-based. Teams with Python-native infrastructure may prefer Python workflow engines like Prefect, Airflow, or Temporal's Python SDK, which allow defining workflows in the same language as the tasks they coordinate. Rill Flow's task executors are HTTP services, so the task language does not need to be Java, but the orchestration layer itself is a Java application.

The input mapping system using JSONPath is powerful but requires understanding the execution context structure and JSONPath syntax. Teams accustomed to workflow tools with native Python or TypeScript definitions may find the YAML-plus-JSONPath approach more verbose for complex data transformations.

Temporal and Apache Airflow as Alternatives

Temporal is the most direct alternative in the durable workflow orchestration space. Both Rill Flow and Temporal handle distributed task execution with retry logic and state persistence. Temporal provides SDKs in Go, Java, Python, TypeScript, and .NET, has a large open-source community, and offers a managed cloud version. Rill Flow differentiates with its visual DAG editor and the explicit AIGC/LLM integration focus; Temporal does not bundle a visual flow editor as a first-class component.

Apache Airflow targets data engineering pipeline scheduling rather than low-latency task orchestration. It runs DAGs of Python operators on a schedule, primarily for batch data transformation workflows. Airflow is not designed for sub-100ms latency task execution; Rill Flow's stated latency target positions it for online or near-real-time coordination rather than nightly batch jobs.

For teams specifically looking for LLM workflow orchestration in a Chinese-infrastructure context, Rill Flow's Weibo provenance and AIGC feature emphasis are relevant differentiators.

Editorial conclusion

Rill Flow suits teams that need a self-hosted workflow engine with a visual DAG editor, YAML-defined flows, and built-in LLM service integration, particularly those in environments where Java infrastructure is already standard. It is not the right fit for teams that need Python-native workflow definition or that require a stable versioned release: the last push was on 2026-04-13 and the repository has no GitHub releases. Before deploying, confirm that the Docker environment can run MySQL, Redis, Jaeger, and the Rill Flow application service simultaneously, since those are all started by the default docker-compose.yml.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. weibocom/rill-flow on GitHub