Proliferate is open source and fully self-hostable. Self-hosting means running the Proliferate server (the API, database, and Web application your team connects to) yourself. Your team opens the server's public URL in a browser to sign in and work, and can optionally connect the official desktop app to that same URL for local repositories and local AnyHarness runtimes. For most teams the hosted service is the recommended setup. Self-host when you have a concrete reason: compliance, data locality, or a network boundary you can't send data across.

Choose your path

Just trying Proliferate?

You don't need a server. Download the desktop app and everything runs on your machine.

Want to develop locally?

Read the docs in Github and we'll get you going in no time.

Self-host for your team

Stand up the server in about 15 minutes, then open its URL in a browser.

Operate & update

One-command updates, version pinning, troubleshooting, and sizing for day-2 operations.

Deploying on a cloud provider? Use the AWS launch stack (one command with launch-stack.sh), or bring Docker to any server (one command with install.sh).

The pieces

A self-hosted deployment is one server, reachable at one public URL, with an optional desktop app and optional add-ons.

Proliferate server (required)

The Docker Compose stack: API, Postgres, migrations, Caddy for automatic HTTPS, and the compiled Web app baked into the server image.

Desktop app (optional, required for local work)

The official signed app, connected to your server from the sign-in screen. Needed for local repositories and local AnyHarness runtimes.

Cloud sandboxes (add-on, coming soon)

Managed cloud workspaces for your organization. Being re-implemented; nothing to configure today.

Model gateway (add-on)

A LiteLLM proxy you run for centralized model credentials and budgets. Without it, users bring their own agent subscriptions.

Your team opens the server's URL in a browser to sign in and work. The official desktop app connects to that same URL and is where local repositories and local AnyHarness runtimes live. The base install already gives you sign-in with email and password, one shared organization (self-hosted servers run in single-org mode by default), invitations, and workspaces that run on each user's machine. First run is never gated on add-ons. GitHub and Google sign-in are optional layers on top.

Not in self-hosting yet

Being upfront about the gaps today:

Automations and scheduled background jobs are not available on self-hosted servers yet; the stack does not ship a worker tier.
Full provider sign-in on the Web app (GitHub, Google, OIDC, SAML) is still being finished; see the authentication pages for what each provider supports today.
Desktops connect from the sign-in screen (or a one-line config file for fleets); proliferate://connect deep links and switching servers without signing out are planned.
Cloud sandboxes (managed cloud workspaces) are being re-implemented and are not available yet.

How updates work

Updating is one command on the server (./update.sh): pull the new image, run migrations, restart. The server reports its versions at GET /meta, and your users' desktop apps follow the version the server pins, so updating the server updates the whole fleet. See Updates & versioning.

Telemetry

Self-hosted servers run with PROLIFERATE_TELEMETRY_MODE=self_managed: anonymous, first-party telemetry only, with no third-party vendors. Set PROLIFERATE_ANONYMOUS_TELEMETRY_DISABLED=1 for zero telemetry. See Telemetry & privacy.

Overview