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.

Self-host for your team

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

Add cloud sandboxes

Enable cloud workspaces with a public HTTPS URL, a GitHub App, and an E2B key.

Operate & update

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

Enterprise controls

Kubernetes, air-gapped operation, SCIM. Get in touch.

Deploying on a cloud provider? Use the AWS one-click stack, or bring Docker to any server.

The pieces

A self-hosted deployment is one server, reachable at one public URL, with an optional desktop app and two 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, pointed at your server via one config file. Needed for local repositories and local AnyHarness runtimes.

Cloud sandboxes (add-on)

Cloud workspaces for your organization. Needs a public HTTPS URL, a GitHub App, and an E2B key with a template built in your own E2B team.

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; users who only work in cloud workspaces never need to install it. 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: no GitHub App, no E2B account, no model gateway. You can enable them later, or not at all. GitHub sign-in and OIDC SSO 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.
Desktop connects through a one-line config file today; in-product connect and proliferate://connect deep links are planned.
Enabling cloud sandboxes involves manual steps today (creating the GitHub App by hand, building the sandbox template with a script); one-click flows are planned.

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