Aixle Flow
A team-level control plane that turns a Kanban card into an isolated, inspectable coding-agent run with visible cost and output.
- Source repo
- AixleHQ/flow
- Stars
- ★ 34
- Last updated
- today
- License
- Apache-2.0
- Primary language
- Ruby
- FA score
- 43/100 · Major gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformCodex · Claude Code
- Cost
- Free software; you pay for model usage
- Setup effort
- High · needs real infrastructure
- You'll need
- Typical use
- A team where several developers already use Claude Code or Cursor individually wants one shared trigger point and visibility into what each agent run did and cost.
- Not a fit if
- Teams that expect a single docker compose up deployment; first build of agent images is slow
- Solo developers who only want a local CLI and no containers or Temporal infrastructure
- Source review
- 43/100 · Major gaps
What does this agent do, and when should you use it?
Aixle Flow sits above coding agents as a team-level control plane: a Kanban board where each column is bound to a workflow, so dropping a card triggers a run. The core is a DAG workflow engine with retries, approval gates and parallel steps, backed by Temporal for durable, long-running execution. Each agent step runs in its own container and can drive Claude Code, Cursor CLI, OpenAI Codex CLI, Gemini CLI, Antigravity CLI, xAI Grok CLI or Kiro CLI, with MCP as the tool integration layer. The stack is Ruby on Rails 8, PostgreSQL, Redis, React 19, Inertia.js, Mantine 9 and Vite; Docker Compose runs it locally and Kubernetes is the stated production option. Every session records tokens and cost in cents, and the whole team can see the run trail and output without opening a terminal.
When a card is dragged into a board column, the workflow bound to that column starts. The engine executes its DAG steps — the README example uses Plan, Implement, Run tests and Open PR — with retries, approval gates and parallel branches, while Temporal keeps the run durable across restarts. Each step executes inside its own agent container, invoking a coding agent such as Claude Code, Codex or Cursor CLI, and gains tools through MCP; containers are Docker locally and Kubernetes in production. Progress streams to the UI over ActionCable, and the sessions table records the tokens and cents each step consumed. Outputs are the code changes, test results and pull requests the agents produce, plus an auditable record of what ran and what it cost.
- A team where several developers already use Claude Code or Cursor individually wants one shared trigger point and visibility into what each agent run did and cost.
- You want a multi-step coding pipeline — write code, run tests, open a PR — modeled as a visual DAG with a human approval gate before risky steps.
- Non-engineers such as product managers should be able to kick off a coding agent by dragging a card, without touching a terminal.
- You need to self-host the orchestration layer so code and data stay on your own infrastructure, while keeping the freedom to mix coding agents.
- Long-running agent jobs must survive process restarts and resume rather than starting over, which is why durable execution matters to you.
How do you install or deploy this agent?
You need Docker and Docker Compose plus a working make. Clone the repository and enter it:
git clone https://github.com/AixleHQ/flow.git && cd flowCopy the environment template; fill in OAuth secrets there if you want SSO:
cp .env.example .env.development # fill in OAuth secrets if you want SSOBuild the containers, install dependencies and seed the database (the first run builds agent images and takes a while):
make setupStart everything — web, worker, db, redis, traefik and temporal:
make upThen open http://localhost:4000 and sign in. See docs/quickstart.md in the repository for more detail.
How do you use this agent?
Once the stack is up, open the local URL and sign in:
http://localhost:4000Define a workflow with the steps you want (for example Plan, Implement, Run tests, Open PR) and bind it to a board column; dragging a card into that column fires a run. During the run, the sessions table shows the tokens and cost each step spent and the container output streams live. Before opening a pull request, run the project checks:
docker compose exec -T web make check_allWhat are this agent's strengths and limitations?
- Column-to-workflow bindings make a single card drag trigger a full agent pipeline, so non-engineers can start work too.
- The DAG engine ships retries, approval gates and parallel steps, with Temporal providing durable execution for long agent runs.
- Each agent step is isolated in its own container (Docker locally, Kubernetes in production) and per-session token and cent costs are tracked for the team.
- It is not tied to one coding agent: a single platform can mix Claude Code, Cursor CLI, Codex, Gemini CLI, Antigravity CLI, Grok CLI and Kiro CLI.
- MCP-native tool integration and an Apache-2.0 license that permits self-hosting and commercial deployment.
- The first
make setupbuilds multiple agent images and the README concedes there is no 5-minute setup yet; a singledocker compose upis still on the roadmap. - The runtime is heavy: PostgreSQL, Redis, Temporal and Traefik are all part of the stack, and production calls for Kubernetes.
- You still supply accounts and model usage for each coding agent — the software is free but model calls are billed per use.
- Contributions require DCO sign-off and a signed CLA, which adds process for companies doing internal forks.
- All interaction goes through the web board; no CLI- or API-driven orchestration path is documented.
How does this agent compare with similar options?
The README names n8n, Dify, Langflow, Cursor and Temporal as influences. Against general workflow automation such as n8n, Aixle Flow differs by using board cards as the trigger and by building container isolation and per-session token/cost accounting specifically for coding agents; against Cursor's background agents it offers a self-hostable, team-level orchestration layer that can mix several coding CLIs.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Aixle Flow This agent | 43 · Major gaps | Self-hosted serviceFree + model costs | ★ 34 | today | Ruby | Codex · Claude Code |
| mcp-agent | 53 · Major gaps | FrameworkFree + model costs | ★ 8.6k | 9mo ago | Python | Claude.ai · OpenAI API · Claude API |
| Kandev | 74 · Some gaps | CLIFree + model costs | ★ 1.1k | today | Go | Codex · Claude Code |
| Tessera | 74 · Some gaps | Desktop appFree + model costs | ★ 315 | 8d ago | TypeScript | Codex · Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
least_privilege: design docs openly admit three Pundit policies are over-permissive (collaborators can delete projects, any member sees company analytics/sessions), showing a real over-privilege surface; scored 1. user_confirmation: README mentions approval gates and a delete confirm modal, but no code evidence and destructive defaults are not shown; 1. data_flow_transparency: cloud-connection-security doc thoroughly describes prompt/credential flow, storage locations, and CloudTrail attribution; 2. sensitive_data_handling: tokens encrypted, session containers never receive Identity Center material, short-lived creds not persisted — but §3b long-term keys are injected into every session container, self-disclosed risk; 2. dependency_security: only a THIRD-PARTY-LICENSES.md reference, no audit or lockfile evidence; 1. external_effects: agents execute in containers, open PRs, call AWS — high external impact, but only documented, no isolation/limit code shown; 1. rollback: disconnect deletes tokens, sessions expire, but project deletion is a hard destroy with no soft-delete/recovery; 1. source_attribution: README has Inspired-by plus NOTICE/TRADEMARK, Apache-2.0 attribution clear; 2.
self_consistency: design doc contains an internal contradiction (AC demands 403 while behavior is 302, self-flagged as blocking), and the research doc references palad-app inconsistent with the repo name; 1. dependency_availability: README lists Rails/React/Temporal stack and make setup, but no lockfile or version-pin evidence; 1. failure_messages: quickstart has troubleshooting (EACCES, Yarn warnings) and cloud doc describes health check surfacing AWS errors, but error handling evidence is scattered; 1.
audience_and_scenarios: README clearly targets teams with a three-tier docs split; 2. capability_boundaries: lists seven supported CLIs and container isolation, but boundaries (what is unsupported, permission ceilings) are scattered in design docs; 1. trigger_precision: board column bindings trigger workflows, but trigger precision, dedup, and concurrency control lack code evidence; 1. environment_fit: Docker, 8GB RAM, Linux permission handling documented, but production Kubernetes path is one line; 1.
information_architecture: README three-tier docs table and structure are clear; 2. install_notes: quickstart is complete with prerequisites and troubleshooting; 2. naming_stability: repo name flow vs palad-app vs Aixle Flow are mixed across docs, consistency questionable; 1. examples_and_faq: example workflow and troubleshooting exist but no formal FAQ; 1. known_limitations: README/quickstart admit the 5-minute goal is unmet, agent image build is slow, and §3b key path is least preferred; 2. license: Apache-2.0 explicit with NOTICE, THIRD-PARTY-LICENSES, TRADEMARK, CLA/DCO; 3. versioning_changelog: Release badge present but no CHANGELOG content; 1. maintenance_responsibility: publisher unverified, CONTRIBUTING referenced but the responsible maintainer is unclear; 1.
output_usability: claims board, cost metering, audit log, but all are README assertions with no verifiable output artifacts beyond a GIF; 1. marginal_value: the incremental value over raw Cursor/Claude Code (team visibility, cost tracking) is argued plausibly but lacks comparative evidence; 1. cost_benefit: per-session cost tracking and Temporal durability exist, but no cost data or benchmarks; 1.
claim_traceability: design docs cite specific file line numbers (strong traceability), but README market claims (only open platform) are unsupported; 1. cross_source_corroboration: README, quickstart, and design docs corroborate stack and flow, but the research doc's palad-app reference conflicts with the repo, weakening corroboration; 1. fact_inference_separation: cloud doc clearly separates fact from inference (self-discloses device-code phishing risk), but README marketing mixes claims with facts; 1.
- Design docs admit three Pundit policies are over-permissive (collaborators can delete projects, any member sees company analytics/sessions); confirm these fixes are merged before deployment.
- §3b long-term Bedrock keys are injected into every session container of that developer and may have no expiry — a high-risk path; prefer the Identity Center path and scope permission sets.
- Project deletion is a hard destroy with no soft-delete or recovery window; destructive operations lack rollback guarantees.
- Repo name flow is mixed with palad-app across docs; publisher identity is unverified and the responsible maintainer is unclear.
- README market claims such as 'the only open platform' are unsupported and should not be used to infer capability or safety.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
Release notes excerpt
Added - Admin: a company's queue breakdown on the dashboard shows its waits by hour of the day, in your own time zone: for each hour, how many of the sessions that joined the queue then waited, and their p95. Its days are in your time zone too, and opening a day shows that day's hours. - Sign-in & onboarding: the hosted product publishes its Terms of Service, Terms of Use and Privacy Policy at /legal, linked from the sign-in page and the app's footer. Everyone accepts the Terms of Use the first time they sign …View on GitHub ↗ -
Release notes excerpt
Added - Sign-in & onboarding: Aixle Flow can be bought on AWS Marketplace. A buyer who subscribes is sent to a page of ours that sets their workspace up: they are signed out first and create a new workspace, confirming the address by email as any other signup does — the subscription proves the purchase, not the address. Returning from Manage subscriptions reaches the workspace they already made. The workspace is billed by AWS rather than by card, gets no free trial, and runs as soon as AWS confirms the agreement; …View on GitHub ↗ -
Release notes excerpt
Added - Profile: the trigger_workflow tool of personal access takes an optional idempotency_key. A second call with the same key returns the run the first call started instead of starting another, so an agent can retry safely after a timeout. - Sessions & Runs: a new workflow run records how it was started: from the workflow page, through personal access, as a retry of a failed run, or by a trigger. A retry links to the run it repeats. get_workflow_run, list_workflow_runs and the admin run page show both. …View on GitHub ↗
FAQ
The license is free — where does the cost come from?
Do I need Kubernetes?
make up starts web, worker, db, redis, traefik and temporal. Kubernetes is only mentioned as the production option.Which coding agents are supported?
What happens to a run if a service restarts mid-flight?
What is required to contribute?
good first issue, run docker compose exec -T web make check_all before opening a PR, and sign both the DCO and the CLA.