Skip to main content
Flowfield supports running independent tasks in parallel — each in its own isolated Git checkout, using its own worker slot. This speeds up work that doesn’t need to happen sequentially. Dependencies ensure tasks that must wait actually do, while truly independent tasks can run side by side without risk of interference.

​
Enable Parallel Workers

By default, each project starts with a single worker slot. To allow two independent tasks to run at the same time, increase the limit in the browser.
1

Open the browser

Navigate to localhost:8765 and open your project.
2

Open Workers settings

Click the settings icon beside your project name and navigate to Workers.
3

Set Maximum Parallel Workers to 2

Change Maximum Parallel Workers from 1 to 2 and save the setting.
4

Move both tasks to Up Next

Ensure both tasks you want to run in parallel are in Up Next on the board. Tasks in Backlog won’t start even if a worker slot is free.
5

Click Run Queue

Click Run Queue (or run flowfield project workers run). Flowfield will start both eligible tasks immediately, each in its own isolated checkout.

​
How Isolation Works

Each worker receives its own Git checkout and runtime environment. Workers clone from your repository’s committed baseline, apply their own changes in isolation, and never touch each other’s files or your main project directory. Two workers can safely run the same codebase simultaneously without conflict. Machine-wide tools and credentials are shared — workers inherit the same environment your terminal session uses. This means installed language runtimes, package managers, and authentication tokens are available to all workers running on the machine, but their working copies of the code remain completely separate.

​
Task Dependencies

Dependencies tell Flowfield which tasks must finish before others can start. Use them whenever one task’s output is genuinely needed by another.
  • Add a dependency when one task’s code must be in place before the next task begins
  • A task with an unfinished dependency stays in Backlog or Up Next and won’t start, even if a worker slot is free
  • Once a prerequisite task is Done — meaning its code has been approved and delivered — dependent tasks become eligible to run
  • Dependencies are set on tasks directly, not on milestones
To set a dependency, ask your coordinator to add it, or use the task edit options in the browser or CLI.

​
Milestones vs. Dependencies

Milestones group related tasks together for organisation and visibility. They don’t gate execution in any way — a task in a milestone can start as soon as its own task-level prerequisites are satisfied, regardless of whether other tasks in the same milestone are finished. Only explicit task-to-task dependencies control execution order. If you want a task to wait, add a dependency. Grouping tasks under the same milestone is not enough.

​
Waiting for Review

When a worker finishes and the task moves to In Review, its worker slot is freed immediately. Flowfield doesn’t hold the slot while you read the result and decide whether to approve it. If another eligible task is waiting in Up Next, it can start in that slot while you review. This means your review step never blocks parallel work. You can approve one result while a second worker is already making progress on the next task.

​
Inspect Relationships

To see a task’s dependencies and the tasks that depend on it:
This lists the task’s prerequisites (what it’s waiting on) and its dependents (what’s waiting on it). Use --relation dependents or --relation prerequisites to filter the output, or --relation blocked_by to see which unfinished prerequisites are currently blocking it.
Break large features into small independent tasks where possible. Smaller tasks run faster, are easier to review, and fail safely if a worker needs to stop — you only lose the work on one small piece rather than a large combined effort.
Keep project and service state outside shared temporary directories when running parallel workers. Workers share the machine’s filesystem but operate in isolated checkouts — avoid pointing configuration or build output at paths that multiple workers could write to simultaneously.