Announcing Proliferate
Proliferate
Getting startedQuickstart

Quickstart

Stand up a self-hosted Proliferate server in about 15 minutes.

This guide takes you from a fresh Linux host to a working team install: the Proliferate server (the API, database, and Web app your team connects to) running under Docker Compose, the instance claimed by you as its first admin in a browser, your desktop app connected and signed in, and your first teammate invited. Budget about 15 minutes of hands-on time, plus whatever your DNS takes to propagate. The Docker page covers the server pieces in more depth.

Provision a host

Before you start, make sure you have:

  • A Linux host (x86_64 or aarch64) with Docker Engine and the Compose v2 plugin installed
  • A DNS name pointed at the host (for example proliferate.company.com) — or skip this and use the installer's --eval mode below for a quick, domain-less evaluation
  • Ports 80 and 443 reachable from your users, and from the internet so Let's Encrypt can issue certificates

Install

The installer resolves the newest published server release itself, verifies its checksum, installs it to /opt/proliferate, and boots the stack. Inspect it before running it as root:

curl -fsSLO https://raw.githubusercontent.com/proliferate-ai/proliferate/main/server/deploy/install.sh
less install.sh
sudo bash install.sh --domain proliferate.company.com

Or pipe straight to a shell if you trust the source:

curl -fsSL https://raw.githubusercontent.com/proliferate-ai/proliferate/main/server/deploy/install.sh \
  | sudo bash -s -- --domain proliferate.company.com

No domain to test with yet? sudo bash install.sh --eval derives a hostname from the host's public IP (<ip>.sslip.io) and still gets real Let's Encrypt TLS, with no DNS setup at all. Pass --version X.Y.Z to pin a specific release instead of the newest one.

The installer resolves the newest server-v* release (never GitHub's generic "latest", which is usually a bundle-less tag), downloads and checksum-verifies the deploy bundle, installs it to /opt/proliferate/server/deploy, generates .env.static with SITE_ADDRESS and the pinned image tag already set, runs the same configuration preflight bootstrap.sh runs, and brings the stack up. It ends by printing the claim URL:

Installed server-v0.3.18

  Control plane:  https://proliferate.company.com
  Claim page:     https://proliferate.company.com/setup   (open in a browser with the setup token above)

  Manage this instance from /opt/proliferate/server/deploy:
    Update:   sudo /opt/proliferate/server/deploy/update.sh
    Doctor:   sudo /opt/proliferate/server/deploy/doctor.sh

The setup token itself is printed just above this block, and is never served over HTTP: it lives in a file inside the API container (/var/lib/proliferate/setup/setup-token) that only someone with shell access to the host can read, so a publicly reachable server is safe while it waits to be claimed. It stays available until you claim the instance; rerun sudo /opt/proliferate/server/deploy/doctor.sh at any time to check status, or sudo /opt/proliferate/server/deploy/wait-for-health.sh to print the token again. The installer is idempotent: rerunning it refreshes the scripts without touching your .env.static, generated secrets, or data. Prefer to fetch the bundle and run bootstrap.sh yourself instead of the installer script? See Docker on any server.

Claim your instance

Open the claim URL in a browser and enter your email, a password, and the setup token. The organization name field is optional: leave it blank and the name is derived from your email domain (the derived default shows as the placeholder). Submitting creates your account, makes you the owner of the organization, and permanently closes open signup: after the claim, /setup returns 404 forever.

Self-hosted servers run in single-org mode out of the box: SINGLE_ORG_MODE defaults to on whenever PROLIFERATE_TELEMETRY_MODE is not hosted_product, so there is exactly one organization and everyone you invite joins it. No configuration needed.

Connect the desktop app

Everyone can already work from a browser at https://proliferate.company.com. Connect the desktop app too if you or your teammates need local repositories or a local AnyHarness runtime: download the desktop app, open it, and choose Connect to a server on the sign-in screen. Enter https://proliferate.company.com; the app verifies it is a Proliferate server, shows you the host and server version, and relaunches connected to it.

For fleets and automation you can write the same setting to ~/.proliferate/config.json instead:

{
  "apiBaseUrl": "https://proliferate.company.com"
}

The file is read once at startup, so restart the app to apply it. Add "telemetryDisabled": true to the same file to turn off desktop telemetry for that install. See Connect the desktop app for details and fleet rollout.

Sign in

Open the app and sign in with the email and password you set at /setup. The desktop app asks your server which sign-in methods it offers (GET /auth/desktop/methods); when GitHub OAuth is not configured, the email and password form is the default. The base install needs no OAuth app at all.

To offer GitHub sign-in as well, create a GitHub OAuth app with callback URL https://proliferate.company.com/auth/github/callback, set GITHUB_OAUTH_CLIENT_ID and GITHUB_OAUTH_CLIENT_SECRET, and restart the server. See GitHub sign-in.

Invite your team

In the desktop app, invite each teammate by email. Registration is invite-only and proven by a token: creating an account requires the invitation token from the invite link, and the server answers any unknown or mismatched token with the same 403.

Every pending invitation in the members list has a Copy invite link action. The link points at your server's registration page with the token and email prefilled:

https://proliferate.company.com/register?token=<invitation-id>&email=<email>

Share the link with your teammate. They open it in a browser, choose a password, and get an account in your organization. Then they install the desktop app, connect it to your server from the sign-in screen, and sign in. If you configure email delivery (Resend is optional), the server emails the same link for you instead. Inviting the same email again issues a fresh link and the old one stops working.

Invitation roles are honored: invite someone as an admin and they are an admin the moment they register. Set ALLOWED_EMAIL_DOMAINS to additionally require that invited emails belong to your domains.

Info:

Set ADMIN_EMAILS in .env.static to guarantee admins: every listed email holds at least the admin role, asserted at every sign-in. It is also the lockout recovery path: add your email to the list, restart the server, sign in. Removing an email never demotes anyone, and the last admin can never be demoted or removed. The flip side: listed emails are reinstated as admin at their next sign-in even after removal, so to offboard someone on the list, remove them from ADMIN_EMAILS too and restart.

Updating

Updating is one command, from /opt/proliferate/server/deploy:

sudo ./update.sh   # pull the new image, run migrations, restart

Your server reports its versions at GET /meta, and desktop update checks go through your server (GET /desktop/updater/latest.json redirects to the official signed build matching the version your server pins). Connected desktop apps follow the server, so updating the server updates the whole fleet. See Updates & versioning.

What's not here yet

Info:

One honest limit of self-hosting today: automations and scheduled background jobs are not available yet, because the self-hosted stack does not ship a worker tier.

Next steps

On this page