Core components
The core components that make up Proliferate.
Proliferate is built from a small set of components that each own one job. This page introduces them one at a time. Architecture covers how they connect and who owns what at the boundaries.
Workspaces
A workspace is the unit of work: a repository checkout with an agent attached to it. Every workspace is one of three targets:
| Target | Where it runs |
|---|---|
| Local checkout | Directly in an existing repo on your machine. |
| Worktree | A clean branch and working tree on your machine, isolated from other work. |
| Cloud workspace | A remote sandbox that keeps running after you close your laptop. |
Inside any workspace you get the same set of tools: chat with an agent, terminals, a file browser, and git review. Read Workspaces & environments for the full guide.
Agents and harnesses
An agent is the coding assistant doing the work: Claude Code, Codex, OpenCode, Cursor, and others. Proliferate calls each one through its own native harness (its CLI or agent protocol) rather than reimplementing it, so your existing login, tools, and model access carry over. See Agents for the supported list and per-agent notes.
AnyHarness: the runtime
AnyHarness is the runtime process that actually drives a session. It sits between the client and the agent: it starts the agent process, keeps its session state, streams events back as the agent works, and exposes the terminals, file operations, and git commands a workspace needs.
One AnyHarness runtime backs one workspace target. For a local checkout or worktree, it runs as a background process on your machine, launched automatically by the desktop app. For a cloud workspace, the same runtime runs inside the remote sandbox instead. Either way, the client talks to it over the same local-style API, which is why a workspace looks and behaves the same regardless of where it's running.
The desktop app (and web)
The desktop app is the primary client: a native app (built on Tauri) that renders your workspaces, chats, terminals, file browser, and git review, and launches the local AnyHarness runtime for local work. A web client covers browser-based access to cloud workspaces and account settings, for when you want to check in or make a quick change without the desktop app open.
Desktop app workspace sidebar
The sidebar listing local, worktree, and cloud workspaces, with status indicators for git and pull request state.
The cloud control plane (Server)
The server is the source of truth for anything that has to survive past a single machine: accounts and organizations, workspace records, connected integrations, billing, and policy. It's also what provisions and manages cloud sandboxes, and what the two gateways below are built on top of. Self-hosted installs run this same control plane on infrastructure you own.
The model gateway (LiteLLM)
By default, an agent authenticates the same way it would on your own machine: your Claude subscription, your Codex login, or your own API key. When you want centralized keys, shared managed credits, or per-user and per-organization budgets instead, Proliferate can route that agent's model calls through a gateway built on LiteLLM. The gateway holds the real provider keys and hands out short-lived, budget-scoped keys to agents instead. In Proliferate Cloud this is managed for you; self-hosted installs can point at their own LiteLLM proxy and use their own provider keys. See Models & authentication for how routing and credentials work day to day.
Organization budgets settings
Org settings showing separate compute and LLM credit budgets, with per-member usage.
The integrations gateway
When an agent needs to reach Linear, Notion, Slack, or another connected tool, it calls a single Proliferate-hosted MCP gateway rather than holding credentials for every provider it might use. The gateway looks up your connected account, calls the provider on the agent's behalf, and returns the result. The agent only ever sees the Proliferate gateway; your Linear token or Notion OAuth grant never leaves the control plane.
Integrations settings pane
The user settings pane for connecting integrations, showing connected accounts with health status and a connect flow for a new provider.
Integration credentials always stay server-side; there is no mode where an agent holds your Linear key or Notion token directly. Model provider credentials stay server-side only when that agent is routed through the model gateway; with native sign-in, the agent holds your own credential, the same as it would running outside Proliferate.