# Rill Flow starts as a Docker Compose stack, not a binary

> A Java workflow orchestration engine whose quickstart is three Compose commands, one pasteable YAML flow definition and a Test button, with no released version to pin and a sample definition that stops mid-key.

**weibocom/rill-flow** —  Rill Flow is a high-performance, scalable workflow orchestration engine for distributed workloads and LLMs

- Repository: https://github.com/weibocom/rill-flow
- Website: https://rill-flow.github.io
- Stars: 410 · Forks: 50
- Language: Java
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/weibocom-rill-flow

## Compose brings up MySQL, a cache and a Jaeger container before any flow

Rill Flow ships as source, not as a binary or a package, so the first thing that runs is a Compose stack from the docker/ directory of the clone. That stack pulls in the stateful side of the system before a single task can be submitted, and the quickstart tells you what to expect:

```shell
docker-compose ps
```

```txt
           Name                         Command               State                                           Ports
------------------------------------------------------------------------------------------------------------------------------------------------------------
rill-flow-mysql              docker-entrypoint.sh --bin ...   Up      0.0.0.0:3306->3306/tcp, 33060/tcp
rillflow_cache_1             docker-entrypoint.sh redis ...   Up      6379/tcp
rillflow_jaeger_1            /go/bin/all-in-one-linux         Up      14250/tcp, 14268/tcp, 0.0.0.0:16686->16686/tcp, 5775/udp, 5778/tcp,
```

Three container names are worth reading closely. rill-flow-mysql publishes 0.0.0.0:3306->3306/tcp to every interface on the host, so a default install leaves the database reachable from the local network. rillflow_cache_1 stays on 6379/tcp with no host mapping at all. rillflow_jaeger_1 runs /go/bin/all-in-one-linux and publishes only 16686, keeping 14250, 14268, 5775/udp and 5778 inside the Compose network.

## The one-click start command does not survive Compose V2

Everything rests on two commands copied straight out of the quickstart:

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

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

A note under the start step says that if your system has Docker Compose V2 installed instead of V1, use docker compose rather than docker-compose, and points you at `docker compose version` to find out which one you have. That note rewrites the start command only. The verification step printed a few lines below still uses the hyphenated V1 spelling, so on a V2 install you follow the instructions literally and end up with a status command that fails until you translate it yourself. The README does not document stopping the stack, dropping the MySQL volume, or moving to a newer image.

## The admin console opens on port 80 with admin/admin

Once the stack is up, the management background is served at http://localhost on port 80 by default, and the credential pair given in the quickstart is admin/admin. There is no first-run step that changes them and no onboarding screen. The console lands straight on the Flow Definition menu, so the distance between an empty install and a running task is four actions: open the Flow Definition List page, click Create, land on the Flow Graph Edit page, flip the one-click import switch and paste YAML. For an evaluation that is a fast loop, and a hosted sandbox at https://rill-flow.cloud with sandbox/sandbox as the login lets you walk it before touching Compose at all. What you get is bare HTTP on port 80 with fixed credentials, so put something in front of it before that port leaves a trusted machine.

## Task names double as the DAG edges in an importable flow

The flow you import is a YAML document whose identity sits entirely in its header: version 1.0.0, workspace rillFlowSimple, dagName greet, alias release and type flow. The input contract is a folded scalar, the >- marker followed by a JSON array declaring two required String inputs named Bob and Alice. Inside tasks, the graph is addressed by name rather than by edge id. Each entry carries category function, a resourceName, pattern task_sync, and a next field whose value is the following task's name, so Bob points directly at Alice. Data movement is declared separately in inputMappings, where source $.context.Bob hands its value to target $.input.Bob. The practical consequence is that the label is the join key: rename a task and you must fix its next reference and every mapping source that names it.

## The sample flow definition ends mid-key on the second task

The block pasted into the import switch is a fragment, and it breaks in an awkward place. This is the whole thing:

```yaml
version: 1.0.0
workspace: rillFlowSimple
dagName: greet
alias: release
type: flow
inputSchema: >-
  [{"required":true,"name":"Bob","type":"String"},{"required":true,"name":"Alice","type":"String"}]
tasks:
  - category: function
    name: Bob
    resourceName: http://sample-executor:8000/greet.json?user=Bob
    pattern: task_sync
    tolerance: false
    next: Alice
    inputMappings:
      - source: "$.context.Bob"
        target: "$.input.Bob"
  - category: function
    name: Alice
    resourceName: http://sample-executor:8000/greet.json?user=Alice
    pattern: task_sync
    tolerance
```

The first task is complete: resourceName, pattern, tolerance false, next Alice and its inputMappings pair. The second stops at a bare tolerance key with no value, no next edge and no inputMappings, so Alice is declared but linked to nothing. Pasted as printed, the graph has a start and one dead end. That is also the entire explanation of the key, since tolerance shows up once as false and once as a nameless flag while no page in the walkthrough says what it changes when a task fails.

## resourceName targets a host that only resolves inside Compose

Both tasks aim their resourceName at http://sample-executor:8000/greet.json?user=Bob, a bare Docker service name on port 8000. That hostname resolves on the Compose network and nowhere else, which reveals the addressing model: a flow calls an executor endpoint, and the executor is a sibling container. Nothing in the walkthrough shows how to point a task at an endpoint outside the stack, and the import path exposes no field for rewriting resourceName, so reaching a real API means editing the YAML before you paste it. The overview also promises rapid integration of LLM model services and the feature list promises plug-in access, yet the walkthrough contains no LLM task category, no provider name and no endpoint to copy. The executors/ and rill-flow-plugins/ directories in the tree are where that work would live.

## Test and Execution Records are the whole feedback loop

Running an imported flow takes three clicks on the Flow Graph Edit page: Test, fill in the required parameters, Submit. The console jumps to the execution details page, and the Execution Records button is where you read status and per-task detail. That is the entire feedback loop the quickstart documents, which leaves the operational questions open: no failure mode, no retry count, no timeout setting, and no statement of what a partial DAG does after the first task fails. The overview's headline figures, tens of millions of tasks per day and task execution latency under 100ms, arrive with no hardware description, no task shape and no measurement procedure attached. The published site is https://rill-flow.github.io/en/docs/intro with a Chinese edition at https://rill-flow.github.io/docs/intro, and the status walkthrough it points at is the relative path ../user-guide/04-execution/03-status.md.

## Nothing is tagged, and the engine sits apart from its executors

The repository publishes no GitHub releases, so there is no version to pin and nothing to upgrade toward. The last commit on the default branch main landed on 13 April 2026 and the project is not archived, which means a clone is always a moving target rather than a released artifact. The tree describes the architecture more plainly than the prose does. A root pom.xml and lombok.config mark it as a Maven Java build, and the sibling modules split along clear lines: rill-flow-dag, rill-flow-impl, rill-flow-service and rill-flow-web on the engine side, rill-flow-ui for the console, rill-flow-interfaces and rill-flow-common for shared contracts, plus rill-flow-plugins, rill-flow-task-template, rill-flow-trigger and rill-flow-test. At the top level, executors/, flow-graph/, flow-let/ and docker/ hold the runnable pieces. Licensing has no ambiguity to resolve: a LICENSE file at the root and Apache-2.0 named in the project summary, with no competing second license.

## Conclusion

Rill Flow earns a trial if you want a visual DAG editor for distributed work and are willing to drive it through a Compose stack and hand-edited YAML. Verify three things first: the sample flow definition in the quickstart is incomplete, so the tolerance key and the second task edges have to come from the published docs; there are no releases to pin, so plan on source builds; and the console is plain HTTP on port 80 with admin/admin, which needs a real access path before it is exposed. The gap to close first is that no failure, retry or timeout behavior is documented anywhere in the walkthrough.

## FAQ

### How do you start Rill Flow, and what does a healthy stack look like?

Clone the repository, change into rill-flow/docker and run docker-compose up -d, then check status with docker-compose ps. The expected output lists rill-flow-mysql, rillflow_cache_1 and rillflow_jaeger_1 all in the Up state, with MySQL published on 0.0.0.0:3306.

### What are the login details for the Rill Flow console?

The management background is served at http://localhost on port 80 by default, with admin as the user and admin as the password. A hosted sandbox at https://rill-flow.cloud uses sandbox and sandbox for both fields.

### Does the Rill Flow quickstart work with Docker Compose V2?

The start command is written as docker-compose up -d. A note says V2 installs should use docker compose instead, and points at docker compose version to check which one is present, but the verification command further down still uses the V1 spelling.

### What does the tolerance setting do in a Rill Flow flow definition?

The key appears as tolerance: false on the first sample task and as a bare tolerance with no value on the second. The walkthrough does not explain what it changes when a task fails, so the behavior has to come from the published documentation.

### Can a Rill Flow task call an API outside the Compose network?

Both sample tasks use category function with a resourceName pointing at http://sample-executor:8000/greet.json, which is a Compose service name resolvable only inside the stack. No field in the import path is shown for rewriting it to an external endpoint.

### Who maintains Rill Flow?

The contributor list names eleven people and marks three as Maintainer: axb (qdaxb), techlog (techloghub) and ch15084 (ch15084). The repository publishes no GitHub releases, so there is no release history to check ownership against.

## Sources

- [Issues](https://github.com/weibocom/rill-flow/issues)
- [License: Apache-2.0](https://github.com/weibocom/rill-flow/blob/main/LICENSE)
- [Project website](https://rill-flow.github.io)
- [README](https://github.com/weibocom/rill-flow/blob/main/README.md)
- [weibocom/rill-flow on GitHub](https://github.com/weibocom/rill-flow)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/weibocom-rill-flow