One container per issue
Every issue reserves its own container and its own checkout from a managed pool. Two agents never share a working tree, so ten issues can move at once without stepping on each other.
Agent-driven delivery pipelines
From issue to pull request, automatically.
Conveyor.AI is a single long-running factory that drives every issue through your pipeline — planning, implementation, review, the test gate, the PR — with coding agents working in their own isolated container, one per issue.
- One container per issue
- Pipelines declared in YAML
- Runs on Docker or Fly.io
How it works
Three moving parts, and one of them is you.
-
1
Describe the work
Open an issue with a title and a paragraph of intent. The moment its status matches a step in your pipeline, the factory picks it up — no kicking off a job, no copying context into a chat window.
-
2
Agents run the stages
Each stage runs a tool in the issue's own container: shape the work, write the code, review it, run the gate, open the pull request. Output streams into the dashboard while it happens.
-
3
You answer the hard parts
When an agent hits a decision it shouldn't make alone, it asks and waits. Answer in the dashboard — or by SMS or WhatsApp — and the stage picks up exactly where it stopped.
Why it holds up
Built for work you actually ship.
An agent that writes code is the easy part. Everything around it — isolation, review, a real test gate, a human in the loop — is what makes the output mergeable.
Pipelines as configuration
A pipeline is a map from issue status to tool, with its own concurrency caps. It lives in version-controlled YAML — shared across projects, or bespoke to one.
A gate that actually gates
A scripted test stage runs your typecheck, your suite and your checks on the exact commit the agent hands it. Red doesn't advance, and CI on the pull request has the final word.
Local metal, cloud overflow
Run containers on your own Docker host, then spill to Fly.io when it fills up. An ordered policy with per-tier caps decides where each one lands — and the pool drains back down on its own.
Live output, not a black box
Watch every run stream as it happens. Questions, comments, progress and a rolling summary all land on the issue thread, so anyone can catch up without reading the log.
Fits the tools you have
Pull requests on GitHub, optional two-way Linear sync, questions over SMS or WhatsApp. Point it at a repo and it builds the development container itself.
The pipeline
Every status is a step. Every step is a tool.
An issue moves from one status to the next, and a stage hands off by setting the one after it. Insert a step, drop one, cap how many run at once — it's a list, and it's yours to change.
- Scripted stages for the objective checks — tests, merges, handoffs.
- Agent stages for the judgement calls, each with its own brief.
- Human gates wherever you want one, including none.
- IntakeIs this clear enough to build?
- PlanningShape it, size it, write it down.
- ImplementationBranch, build, commit.
- ReviewA second agent reads the diff.
- TestingThe gate, on that exact commit.
- MergeRebase, PR, land it.
- DoneDeployed on push to main.
Declarative by default
Your process, in a file you can review.
Tools, workflows and projects are YAML, reconciled into the factory when you push them. Change how work flows the same way you change anything else: a diff, a review, a merge.
- Share one workflow across projects, or give a project its own.
- Cap concurrency per step so a busy backlog can't stampede.
- Tools are just a setup script, a command and some params.
# statuses drive both the pipeline and the board
name: Team Development
statuses:
- { key: implementation, label: Implementation }
- { key: review, label: Review }
- { key: testing, label: Testing }
# a step: on this status, run this tool
pipeline:
- on: implementation
tool: dev-agent
params: { phase: implement }
max: 2 # at most two at a time
- on: testing
tool: test-runner # scripted, not an agent
Get started
Up in three commands.
Deploy the factory once, point it at a repo, and open your first issue. It runs as a single container and manages as many projects as you give it.
# 1 — configure and deploy the factory
$ cp .env.example .env
$ ./scripts/factory.sh up
# 2 — stand up a project container from a repo
$ ./scripts/factory.sh project up owner/repo
# 3 — open the dashboard and file an issue
$ ./scripts/factory.sh url