Skip to content

MergeLoom Docs for Ticket-to-Code Automation

Operator docs

Use these docs to get from a clean environment to your first PR or MR with validation evidence from MergeLoom ticket-to-code automation.

Use the MergeLoom controller at https://controller.mergeloom.ai to create your account, connect integrations, copy worker enrollment values, configure workflow rules, and watch runs.

Know which UI you are using

The customer controller is at https://controller.mergeloom.ai. Use it for accounts, integrations, worker enrollment, workflow rules, repository settings, and job audit state. The local worker UI is available only after you install the worker, usually at http://127.0.0.1:8010/ or through an SSH tunnel to that port. Use it for provider setup, provider readiness, local run streams, and worker-local traces.

The fastest route is:

  1. Install the worker.
  2. Configure an AI provider.
  3. Connect your work tracker and code host.
  4. Configure intake labels and workflow states.
  5. Add the label to a ticket and watch MergeLoom create the review request.
MergeLoom customer controller worker setup page showing tenant slug and worker enrollment token.
Customer controller: copy the tenant slug and enrollment token before installing the local worker.

These docs are written for engineering leads, platform engineers, and workspace admins who need to prove MergeLoom safely in a real workflow.

They focus on the current product shape:

  • customer-hosted worker execution
  • Docker Compose first-run path
  • Kubernetes worker deployment with Helm
  • worker-local provider setup
  • Jira, GitHub Issues, GitLab Issues, monday.dev, Linear, and Azure Boards intake
  • GitHub, GitLab, and Azure Repos review output
  • labels, comments, and workflow state changes
  • repository rules, validation commands, and review controls
MergeLoom-created pull requests linked from the ticket-to-code workflow.
Expected outcome: MergeLoom creates a PR or MR from an approved ticket while your team keeps review and merge control.

The public worker install sources are available here:

For production Kubernetes installs, the Helm chart supports secret.existingSecretName so enrollment tokens and provider API keys can come from your cluster secret workflow instead of Helm values.