LoopForge

https://github.com/user-attachments/assets/8af401d9-1aae-427c-b4bc-455c12d17beb

LoopForge is a self-hosted workspace where your team ships software with coding agents. Describe what you need to Main Bot in chat: it opens a Docker sandbox, checks out your repositories, delegates to project roles, and opens the PR. When a way of working proves itself, save it as an SOP (a standard workflow of agents, scripts and human gates) so the next requirement is delivered the same way, with review and approval built in.

Coding-agent CLIs do the work: CodeBuddy, Codex, Claude Code, OpenCode, Cursor CLI, Antigravity, Kimi Code, Pi, DeepSeek Harness and ZCode. LoopForge adds the roles, sandboxes, checkpoints and history around them, all on your own infrastructure under the MIT license.

Two ways to work

Both paths track the same requirements, so every change, whether made in chat or by an SOP, links back to what was asked for and counts toward delivery and cost reports.

Why LoopForge

Ask a coding agent to "fix this bug" and the result depends on that run. It might skip the plan, forget the tests, review its own code, or stop halfway without anyone noticing. That's fine for a demo, but it isn't how a team ships.

• Repeatable. Same SOP, same stages, same checks for every requirement. Start from built-in backend, frontend, bug-fix and product SOPs.
• Separated roles. Planning, implementation, review and testing each get their own prompt, executor, model, rules, Skills and MCP tools. A role works as an SOP node or as a subagent in chat.
• Human in the loop. Approval gates where they matter. Read the report, approve, or send the work back to a chosen step.
• Observable and resumable. Node status, tool traces, logs and artifacts in one place. Pause, retry a failed step, or rerun from any node.
• Your stack, your servers. Ten coding-agent CLIs as executors, from CodeBuddy, Codex and Claude Code to OpenCode, Cursor CLI and more. GitHub, Skills and MCP as tools. Docker sandboxes or your own machine as the runtime.

Quick start

Install Git and clone the repository first. The installer checks Docker, Compose, Python 3 and curl and offers to install missing components. Python/curl installation supports apt, dnf and yum on Linux; the Compose plugin supports x86_64/arm64 and verifies the official release SHA-256. macOS needs a working Python 3 and Docker Desktop; Homebrew can install missing components. Ordinary Linux users are supported through Docker group access or sudo. Set LOOPFORGE_YES=1 to accept installation prompts. Package and image downloads require internet access.

git clone https://github.com/Tencent/LoopForge.git
cd LoopForge
./start.sh

./start.sh pulls the GHCR release image pinned in compose.yaml without building locally (bash scripts/install.sh does the same). It creates the MySQL and platform services, generates configuration and session secrets, and installs the built-in sandboxes, starter SOPs and welcome project. Host Go and Node.js installations are not required. Configure model API keys and GitHub authorization after startup. Use ./start.sh logs, stop, restart or pull to manage it, and ./start.sh dev to build the checkout from source.

If downloads from ghcr.io stall, set MIRROR to a registry host that can stand in for ghcr.io. ./start.sh pulls from that host and tags the image back to the name pinned in compose.yaml. Setting MIRROR trusts that host, because the download is tagged with the official name. The GitHub Release records the digest; docker image inspect --format '{{index .RepoDigests 0}}' ghcr.io/tencent/loopforge:<pin> should show the same digest after @. Without MIRROR, ./start.sh still pulls ghcr.io directly, and compose.yaml stays unchanged. Upgrade with the same variable and ./start.sh pull. ghcr.nju.edu.cn is one such host. A Docker registry-mirrors entry such as https://docker.nju.edu.cn only accelerates Docker Hub and is not a value for MIRROR.

MIRROR=ghcr.nju.edu.cn ./start.sh

Open the address printed by the installer and create your account; the first one becomes the administrator. The service listens on 0.0.0.0:8090 by default. On a cloud host, the installer reads the public IP from the provider's metadata service and prints it; allow the port in your security group, or put an HTTPS reverse proxy in front. Restrict access to your own IP until the administrator account exists. The home page's quick-access guide walks you through adding a model key, connecting a repository and choosing an SOP.

For GitLab, Gitea, Gogs and other Git hosts, set up Git SSH to check out and push branches with a personal key. PR/MR and Issue automation requires a hosting API token or a separately configured MCP.

Try it without an API key

New accounts join the LoopForge demo project, which includes an SOP made only of a script and a human gate:

1. Switch to the demo project, open Templates, and open Platform check · script & approval.
2. Click Run SOP. A real script writes a report, then the run waits for you at the approval step.
3. Approve it from Needs review or the run page, and watch the run continue to its final artifact.

What you need for real work

• Executors. Pick one of ten CLIs beside the home composer, then a model. Every SOP role can choose its executor independently (built-in roles default to CodeBuddy). Requirement clarification, AI notification summaries, Bot replies and run evals currently use CodeBuddy, so their model pickers list CodeBuddy models only and the server refuses a model of another CLI instead of switching it to CodeBuddy; scheduled assistant tasks run on the CLI the task selects.

  Executor	Credentials	Installation
  CodeBuddy	Personal key, or a shared key an administrator configures for chat and SOP runs	In the Docker image
  Codex	Personal key; a connected execution machine can use its local login	In the Docke