Skip to content
MergeLoom Docs

What is MergeLoom?

MergeLoom turns approved tickets, issues, and feature work into PRs or MRs with validation evidence while keeping AI coding execution on your infrastructure.

At a high level:

  • the control plane coordinates tenants, integrations, workflow rules, job state, and review request creation
  • the worker runs in your environment and performs checkout, context assembly, AI execution, validation, repair attempts, and branch push
  • your work tracker supplies the ticket or issue
  • your code host receives the branch and PR or MR
  • your AI provider runs inside the worker execution path you approve
MergeLoom architecture diagram showing development tools, the MergeLoom controller, and the customer-hosted worker.
MergeLoom coordinates work in the controller while the worker performs code checkout, context assembly, model calls, tests, and PR or MR preparation on your infrastructure.

Control plane

Section titled “Control plane”

The MergeLoom controller at https://controller.mergeloom.ai is the coordination layer. It stores workspace configuration, integration state, repository catalog settings, workflow state mappings, worker enrollment, job metadata, and review output coordination.

Use the customer controller for account access, integrations, repository catalog settings, workflow rules, worker enrollment, and job audit state.

It is responsible for:

  • connecting Jira, GitHub Issues, GitLab Issues, monday.dev, Linear, Azure Boards, GitHub, GitLab, and Azure Repos
  • discovering eligible tickets or issues
  • creating job envelopes
  • leasing jobs to enrolled workers
  • creating or updating PRs and MRs after the worker completes execution
  • surfacing run state in the MergeLoom controller

Worker

Section titled “Worker”

The worker is where the code work happens.

After installing the worker, open the local worker UI at http://127.0.0.1:8010/. If the worker runs on a VPS, tunnel that port first and then open the same local URL in your browser.

It is responsible for:

  • checking out the repository
  • assembling ticket context, organization context, repository rules, and validation instructions
  • calling the configured AI provider
  • running allowed commands and validation checks
  • retrying bounded repair attempts when validation fails
  • pushing the branch
  • keeping local run history, provider readiness, and live stream state
MergeLoom local worker UI home page showing worker runtime status and navigation.
Local worker UI: use this screen for worker-local status, provider readiness, live run visibility, and local run history.

What is a run?

Section titled “What is a run?”

A run is one completed worker execution that produces a review outcome.

For billing and product language, think of a run as:

  • one job leased by a worker
  • one implementation attempt path for a ticket, issue, or manual job
  • one PR or MR creation/update outcome when the job succeeds

If a run is blocked, denied, or fails validation, the run still creates useful trace information for review and troubleshooting.

What stays on your infrastructure?

Section titled “What stays on your infrastructure?”

The worker performs the sensitive execution path:

  • repository checkout
  • context assembly
  • AI execution path
  • validation commands
  • local run traces
  • branch push preparation

MergeLoom is designed so engineering teams can use AI coding automation without handing the full code execution path to a vendor-hosted black box.