Connectivity
Anvil Coder connects to your landscape at three points: at the front, tickets take in the orders; at the back, the result lands as commits in a Git repository; and in the middle, the model layer is interchangeable. All three are built to be replaced individually — the domain logic knows none of these connections.
The entry point is the same gesture on every tracker: a human pulls a story onto the trigger state, the system picks it up, plans, executes and reports the outcome back into the ticket state. On YouTrack and Jira Cloud the trigger is the board’s start status; on GitHub and GitLab it is a label (df:status/ready and df::status::ready) — GitHub and GitLab deliver via webhook within seconds, YouTrack and Jira are polled. A closed or retracted ticket cancels the running work, the same way on all four paths.
The same gesture works one level up: an epic pulled onto the trigger state does not start a run — it decomposes itself. The system reads the project’s foundation documents, hardens the requirement and creates the user stories as real tickets, linked to the epic and deliberately untriggered. Which story actually runs is still a human decision, story by story. This works identically on all four trackers.
Separately (optional), a comment feedback channel can be enabled that starts follow-up runs exclusively in the review states; the hosted service has it switched on.
Anyone who prefers not to work in the ticket has a second workplace, also(optional): the pull-request comment. The service reads along, and an instruction in a comment becomes an incremental follow-up run — the comment is the requirement. This channel is switched on in the hosted service, too.
This is where the system fits into an existing process instead of demanding a new one: whoever pulls stories today keeps pulling them — and whoever reviews in the pull request stays there.
Every completed work step leaves its own commit. What stands at the end is not a text block someone copies out, but a repository with history — readable for humans, verifiable for a pipeline.
In the hosted service the result arrives where review happens anyway: as a draft pull request against the main branch, in a private repository. There is nothing to import — the first look at it happens in the familiar review tool.
Available repository hosts are GitHub, GitLab andBitbucket Cloud; on GitLab and Bitbucket the counterpart is called a merge request instead of a pull request, the flow is the same. GitHub connects through the organisation’s app installation, GitLab and Bitbucket through OAuth 2.0 (GitLab additionally with PKCE) — GitLab is selectable for gitlab.com today; self-managed instances are prepared server-side but not yet selectable as a target. The necessary webhooks are set up by the system itself: per project, each with its own secret that is stored only as a hash — on GitLab and Bitbucket there is no manual webhook step anymore.
A project chooses its tracker at creation. The internal issue board lives right in the cockpit and needs no external tracker instance. For existing processes there are also YouTrack, GitHub Issues, Jira Cloud,GitLab Issues and — for existing projects with the issue tracker enabled —Bitbucket. The tracker is a project property; it is never silently swapped after creation.
All trackers work in both directions: the trigger state starts runs (and epics decompose into stories, see above), results, comments and links flow back. Jira and GitLab connect via OAuth 2.0 (GitLab additionally with PKCE) and load their project and status metadata live. Before the first run, a board check verifies that the tracker board offers every state the manufacturing process needs — missing states are proposed with synonyms for confirmation instead of failing silently. Which connection a project uses can additionally be pinned as a primary or secondary project binding.
Details live in the published guides:internal ticketing,connecting GitHub andconnecting Jira Cloud.
Visible as planned cards in the cockpit, but not yet connectable:Trello and Linear.
For slice generation, three read-only context servers can be enabled: one for YouTrack stories, one for GitHub pull requests and one for a curated text corpus. They give the agent context the requirement itself does not carry.
All three are (optional), off by default and strictly read-only. For the text corpus there is no fallback to shared credentials: an unassigned tenant gets nothing — not another tenant’s data, nothing at all. The same holds for GitHub as long as no shared default access is configured — that too is an operator decision. For YouTrack, a shared default instance can additionally be configured that a not-yet-assigned tenant falls back to — an operator decision, not an exception to the rule.
Each organisation manages its own projects, connections, members and keys. An OWNER or platform admin can issue invitations as shareable links; permissions and data remain scoped to the organisation. A project uses its primary repository and tracker connection and can add further SECONDARY bindings.