# Multica: an open-source board where coding agents pick up issues

> Multica is a self-hostable workspace that assigns issues to AI coding agents the way you assign them to people. It drives agent CLIs you already have installed, and it keeps every run tied to the issue it came from.

**multica-ai/multica** — Multica turns coding agents into managed teammates that pick up assigned issues, write code, report blockers, and update statuses autonomously, all self-hosted.

- Repository: https://github.com/multica-ai/multica
- Website: https://multica.ai
- Stars: 51,676 · Forks: 6,707
- Language: Go
- License: not declared
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/multica-ai-multica

## The problem Multica is aimed at: agents that forget between sessions

The README opens with a scene most people running coding agents will recognise. You have Claude Code, Codex, and three other agents, each in its own terminal tab. Every session starts from nothing, so you re-explain the same context for the fourth time in a day. Adding agents multiplies the babysitting rather than the output.

Multica's answer is to move the unit of work from the terminal session to the issue. An agent is assigned an issue, picks it up on its own, works on a runtime you control, comments as it goes, and hands the result back for review. The intent, the run, the decisions, and the diff stay attached to that issue. The target reader is a small engineering team that already has agent CLIs installed and signed in, and wants the work tracked somewhere other than scrollback.

## Runtimes, agents, and the daemon that keeps code on your machine

The architecture visible in the README is a three-part split. A runtime is any machine agents can work on: your laptop or a cloud box. A daemon runs there, and the README states code never leaves that machine. An agent is a named entry on the board with a provider and a runtime attached, so it appears alongside human teammates. The server holds issues, runs, and the execution log.

The server side is Go. The Dockerfile builds five binaries from server/: server, multica, migrate, and two backfills (backfill_task_usage_hourly and backfill_codex_usage_cache), then runs docker/entrypoint.sh on Alpine. Postgres is the datastore, and docker-compose.yml pins pgvector/pgvector:pg17 with the database name multica and the port bound to 127.0.0.1:5432. The pgvector image choice suggests embedding-based search is expected, though the README does not describe it.

The daemon is the interesting part. It detects which agent CLIs are installed on the machine, and the web UI shows two commands to paste into a terminal to register another computer. Because the CLI inventory lives on the daemon rather than the server, you can put a laptop and a cloud box in the same workspace and route an issue to whichever one has the right CLI signed in.

## Installing Multica and assigning your first issue

The README gives a hosted path and a self-hosted path. Hosted means signing up at multica.ai or downloading Multica Desktop for macOS, Windows, or Linux; the desktop app registers the computer it runs on as a runtime automatically. Self-hosting pulls the official images from GHCR and requires Docker.

The self-hosted install is two commands. The first runs the install script with the server flag; the second initialises the self-hosted setup:

```bash
curl -fsSL https://raw.githubusercontent.com/multica-ai/multica/main/scripts/install.sh | bash -s -- --with-server
multica setup self-host
```

On Windows the README sets an environment variable first and then runs the PowerShell installer:

```bash
$env:MULTICA_MODE="with-server"
irm https://raw.githubusercontent.com/multica-ai/multica/main/scripts/install.ps1 | iex
```

The self-hosting guide is the source of truth here, and the README notes a fallback: if the selected GHCR tag has not been published yet, build from a checkout with make selfhost-build. That is a real failure mode rather than a theoretical one, because releases have landed on consecutive days (v0.4.34 on 2026-08-25, v0.4.35 on 2026-08-26, v0.4.36 on 2026-08-28), and image publication can lag the tag.

Once a server is running, the first real use is the same on hosted or self-hosted. Sign in, connect a computer as a runtime, then create an agent under Agents in the sidebar by picking the runtime, a provider, and a name. The one prerequisite the README states plainly: the machine that will run agents needs at least one supported agent CLI installed and signed in. Multica drives them; it does not ship them. After that, the workflow is to file an issue and set the agent as assignee, exactly as you would pick a colleague.

## Review gates, execution logs, and what a failed run does

The feature that separates Multica from a terminal wrapper is the review gate. Work lands in review, not in main, and a human decides what ships. Every run also produces an execution log the README describes as replayable: each tool call, command, and error, timestamped. Token usage is tracked per agent and per issue, which matters once several agents are running on the same repository and you want to know which one is expensive.

Failures have a defined path. The docs link is titled "Failures and automatic retries", and the README says failed runs retry on their own or stop and tell you why. The README does not document how many retries happen, what the backoff is, or how to override either, so treat those as things to read in the docs before you depend on the default. There is no rollback mechanism described: the review gate is the safety net, not an undo.

## Where Multica is the wrong tool

Multica assumes you already run agent CLIs and are willing to keep them installed, signed in, and updated on at least one machine. If you want a platform that supplies the model and the execution environment in one package, this is the wrong shape: the README is explicit that Multica drives agent CLIs and does not ship them. There is no zero-prerequisite path.

The second constraint is operational. Self-hosting means Docker images from GHCR, a Postgres instance, and migrations run by the container entrypoint. The .env.example exposes pool sizing (DATABASE_MAX_CONNS, DATABASE_MIN_CONNS, defaulting to 25 and 5 per pod), a search work_mem ceiling (DATABASE_SEARCH_WORK_MEM_MB, capped at 64), and an optional read replica (DATABASE_REPLICA_URL) with its own pool. The comments state replica reads may return stale data without a bound and that replica failures fall back to primary. That is a lot of knobs for a team without someone who enjoys tuning Postgres. A single developer running one agent on one repository will find the whole board-and-issue apparatus heavier than the terminal it replaces.

Licensing is unresolved in what is available. The repository has a LICENSE and a NOTICE file, and the Dockerfile copies both into the runtime image, but the licence identifier is not stated. Check the file before you build a redistribution plan on it.

## How Multica differs from running agents directly or using a CI runner

The closest alternative is the status quo: run each agent CLI by hand in its own terminal. That gives you no shared issue history, no execution log, and no review gate, but it also gives you no daemon, no Postgres, and no server to upgrade. If your work is one agent on one repository, the manual path is simpler and the difference in approach is exactly the tracking layer Multica adds.

A second comparison is a CI runner that shells out to an agent on a webhook. CI is event-driven and stateless per job; the run is tied to a commit, not to an issue that a human assigned. Multica inverts that: the issue is the durable object, the run attaches to it, and the agent can comment and raise blockers mid-run. A CI runner also does not give an agent a name on a board or let a teammate reassign work to it. The trade-off is that Multica needs a long-lived daemon on a machine you control, where CI needs only a runner that starts and stops.

The repository also ships examples/plugins/ and a skills-lock.json, which points at a plugin or skill extension path, but the README excerpt does not describe the format. Anyone planning to extend Multica should read the docs on Skills before assuming the plugin surface is stable.

## Maintenance, upgrade cost, and what to pin

The last push to the default branch was on 2026-08-28, the same timestamp as the v0.4.36 release. The repository is not archived. Three releases shipped inside four days that week, which tells you the project moves quickly and that self-hosters should pin a tag rather than track main.

The upgrade path for a self-hosted install is a container image swap plus migrations run by docker/entrypoint.sh on startup. The .env.example documents a retry window for transient database failures across the migration and API startup phases, with 0 meaning a single fail-fast attempt per phase. That knob exists precisely because migrations and API startup can fail against an unreachable database, so an upgrade script that sets it to 0 will surface a bad deploy immediately rather than hanging.

The monorepo layout means the client surfaces move on their own cadence: apps/ holds web, desktop, and mobile, and package.json excludes @multica/mobile from build, typecheck, test, and lint. The README notes iOS builds from source today and is not yet on the App Store, so mobile is a build-it-yourself proposition. Node 22 or newer and pnpm 10.28.2 are pinned in package.json if you intend to build any of the clients from source.

## Conclusion

Adopt Multica if you already run several agent CLIs and lose time re-explaining context in separate terminal tabs, and if you can keep at least one supported CLI installed and signed in on the machine that will act as a runtime. Skip it if a single agent in a single repository is enough for you, or if you want the platform to supply the model: the README states Multica drives agent CLIs and does not ship them. Verify first that the GHCR tag for v0.4.36 has actually been published, because the self-hosting guide points to make selfhost-build from a checkout when it has not, and confirm the LICENSE file's terms before you plan around redistribution.

## FAQ

### What is Multica?

Multica is an open-source workspace where you assign work to AI coding agents the way you would assign it to a teammate. Agents pick up an issue, report progress, raise blockers, and hand the result back for review, with the intent, run, decisions, and diff staying connected to that issue.

### How do I install Multica?

The README gives a hosted path (sign up at multica.ai or download Multica Desktop for macOS, Windows, and Linux) and a self-hosted path. Self-hosting runs the install script with --with-server, then multica setup self-host; it pulls official images from GHCR and requires Docker.

### Is Multica open-source?

The README describes it as an open-source workspace and the repository carries a LICENSE and a NOTICE file, which the Dockerfile copies into the runtime image. The licence identifier itself is not stated, so read the LICENSE file directly.

### Can Multica be used with Claude Code?

Yes. Claude Code is listed among the 23 supported agent CLIs, and the README states the machine that will run agents needs at least one supported agent CLI installed and signed in, because Multica drives them rather than shipping them.

## Sources

- [Official documentation](https://multica.ai)
- [Official README](https://github.com/multica-ai/multica#readme)
- [Project repository](https://github.com/multica-ai/multica)
- [Release notes](https://github.com/multica-ai/multica/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/multica-ai-multica