Turn coding agents into real teammates — assign issues, track progress, and compound reusable skills across a vendor-neutral, self-hosted platform.
Multica is an open-source managed agents platform that treats AI coding agents as first-class teammates rather than tools to babysit. Instead of copy-pasting prompts and manually watching runs, you assign issues to agents the same way you’d assign work to a colleague — they pick up the task, execute it on your local or cloud runtime, post progress updates, raise blockers, and close the loop autonomously.
At the core is a persistent agent daemon that runs on your machine, auto-detects whichever coding CLI is available (Claude Code, Codex, GitHub Copilot CLI, Cursor Agent, Gemini, and others), and maintains a live WebSocket connection to the Multica server. The server orchestrates task queuing, status streaming, and skill storage using a Go backend, a Next.js frontend, and PostgreSQL with pgvector.
Squads extend the model to team-scale routing: instead of assigning work to a specific agent, you assign it to a named squad whose leader agent decides which member picks it up. Autopilots layer in scheduling — cron triggers, webhooks, or manual runs — so recurring tasks like daily standups, weekly reports, and periodic audits run themselves without human initiation.
Skills are the compounding layer: every solution an agent produces can be saved as a reusable skill, making the team progressively faster as institutional knowledge accumulates. Multica is vendor-neutral by design, self-hosted by default, and ships as Docker Compose images with a single-command setup.
make selfhost commandArchitecture Multica follows a clean three-tier architecture with a deliberate separation between the coordination plane and the execution plane. The Go backend acts as the coordination hub — it owns the task state machine (enqueue → claim → start → complete/fail), the WebSocket hub for real-time event push, and all service-layer business logic organized into discrete, single-responsibility service structs (TaskService, AutopilotService, SquadService). The agent daemon is a separate process that runs on developer machines, connects to the backend over WebSocket, and acts as the execution plane — it actually spawns agent CLI processes, streams output back, and manages local repo caches. This split means the server never executes untrusted code, and the daemon can run isolated per-developer without coupling to server availability. PostgreSQL is the authoritative store for all state, with Redis used as a thin cache layer for the empty-claim fast path that avoids unnecessary DB scans when agent queues are idle.
Tech Stack
The backend is written in Go 1.26 using the Chi router for HTTP routing, gorilla/websocket for persistent daemon connections, and sqlc for type-safe database access against PostgreSQL 17 with the pgvector extension enabling semantic search over the skills library. The frontend is Next.js 16 (App Router) with a component library rooted in shadcn/ui conventions, using pnpm workspaces and Turborepo to manage the monorepo. The CLI and daemon are compiled as a single Go binary distributed via Homebrew tap and install scripts for macOS, Linux, and Windows. Production deployment uses Docker Compose with official images published to GHCR; the development stack is a single make dev that provisions the database, runs migrations, and starts all services. Resend handles transactional email for authentication, AWS S3 and Secrets Manager are optional integrations for cloud-hosted deployments, and Prometheus metrics are exposed for operational monitoring.
Code Quality
The Go server has extensive test coverage — well over two hundred test files across handler, service, daemon, scheduler, and protocol packages, with a naming convention of *_test.go paired to each production file. Tests are granular and scenario-named (e.g., autopilot_squad_test.go, task_complete_race_test.go, concurrent_claim_test.go), signaling deliberate testing of race conditions and edge cases rather than just happy paths. Error handling is explicit throughout the service layer: errors are wrapped with context, returned rather than logged-and-swallowed, and the daemon uses typed sentinel errors (ErrRepoNotConfigured, ErrNoRuntimesToRegister) to allow callers to branch on specific failure modes. The frontend has a smaller but present Vitest and Playwright test suite. CI is active and visible via GitHub Actions badge. Code comments in the service layer are dense and explain the “why” — references to specific issue IDs and design decision rationale appear inline.
What Makes It Unique Multica’s most technically distinctive contribution is the execution-plane isolation model: rather than running agent code inside the server (which would require sandboxing, credential delegation, and repo access management at scale), the daemon on each developer’s machine is the only thing that spawns agent processes. This means agents run with the exact same environment, credentials, and file access as the human developer — no special sandbox setup, no credential forwarding protocol, no vendor lock-in to a particular agent runtime. The autopilot admission guard is another concrete differentiator: before scheduling a task, the server checks runtime liveness and records a skipped run with failure reason rather than allowing tasks to pile up against an offline machine. The Skills compounding system backed by pgvector turns the platform into an institutional memory layer, not just a task router. Together these decisions make Multica the only open-source project that treats the full agent lifecycle — from assignment through execution monitoring to reusable skill capture — as a first-class product concern rather than a scripting exercise.
Multica is released under a modified Apache License 2.0. The modification adds two commercial restrictions that self-hosters should read carefully before deploying. First, you may not use Multica source code to offer a hosted or managed service to third parties — internal use within a single organization across unlimited workspaces is explicitly permitted, but reselling access or embedding Multica as a component of a commercial SaaS product requires a commercial license from Multica, Inc. Second, the frontend (the apps/web/ directory) must retain its Multica logo and copyright information; the restriction does not apply if you run only the backend or CLI without the web UI.
Running Multica yourself requires Docker and Docker Compose on a host with enough resources to serve a Go API process, a Next.js server, and a PostgreSQL 17 instance with the pgvector extension. The official path is a Docker Compose stack pulled from GHCR; standing it up takes two commands, and keeping it current means pulling new images on each release (roughly daily at the current cadence of 94 releases in five months). Each developer on the team also needs the multica CLI installed and a background daemon running on their own machine — the daemon is the compute layer that actually executes agent tasks, so developer laptops or dedicated runner machines need to stay online for work to flow. Email delivery (via Resend) is required for authentication in production; the self-host guide documents an alternative fixed-code path for private single-machine setups.
Compared to Multica Cloud, self-hosting means taking full ownership of availability, backups, and upgrades. The cloud tier handles database management, HA, zero-downtime deployments, and managed runtime infrastructure, whereas self-hosted deployments rely on whatever backup and monitoring strategy the operator brings. There is no documented enterprise SLA or support tier for self-hosted installations at this stage; the primary support channel is the public GitHub repository and community. Teams comfortable operating containerized Go services on their own infrastructure will find the self-hosting experience straightforward; teams that need guaranteed uptime or hands-off maintenance should evaluate the hosted option.
Automation · Productivity · AI Assistants
Build, deploy, and run autonomous AI agents that automate complex multi-step workflows using a visual block-based graph editor.
No Code Platforms · AI Development · Developer Tools
Visual LLM workflow platform with RAG pipelines, agent capabilities, and model management for building production AI applications.
AI Code Assistants · AI Development
Orchestrate an army of AI coding agents—Claude Code, Codex, Gemini CLI, and more—running simultaneously in isolated git worktrees from a single Electron desktop app.