By default the desktop app connects to Proliferate Cloud. Your users run the same official signed app and point it at your server from the sign-in screen. Everyone can already sign in and work from a browser at your server's public URL; connect the desktop app on top for local repositories and a local AnyHarness runtime, which the browser cannot provide.

Install the official desktop app

Download and install the desktop app from Proliferate as usual. You never build or distribute a custom binary; self-hosted deployments run the same signed builds as Proliferate Cloud.

Choose "Connect to a server"

On the sign-in screen, choose Connect to a server and enter your server's public URL: https:// plus the SITE_ADDRESS you configured on the server. https is assumed when you leave the scheme off.

The app checks the address is really a Proliferate server (it calls GET /meta) and shows you the host and server version before anything is saved, so a typo fails loudly instead of pointing your session somewhere unexpected.

Confirm the server. The app saves the address and relaunches connected to it, then asks your server which sign-in methods it offers (GET /auth/desktop/methods) and shows the matching sign-in screen.

The sign-in screen shows which server you are connected to, with a reset action that returns the app to Proliferate Cloud. Switching servers while signed in means signing out first: the connect affordance lives on the sign-in screen.

The desktop app adapts to your server's configuration automatically:

Email and password (the default). When GitHub OAuth is not configured on the server, the desktop shows an email and password form. The first account is the one you created when you claimed the server at https://<site>/setup; every other user is invited by an admin and creates their account in a browser through the invite link (the server's /register page; registering requires the invitation token from that link). See Email & password.
GitHub sign-in (optional). Set GITHUB_OAUTH_CLIENT_ID and GITHUB_OAUTH_CLIENT_SECRET on the server, with the OAuth callback URL https://<site>/auth/github/callback, and the desktop offers GitHub sign-in. See GitHub sign-in.

What the desktop shows for your server

The desktop never assumes Proliferate Cloud just because a server answers health checks. On connect, it also reads a small capability contract off GET /meta and renders only what your server actually declares: a self-managed server shows no vendor billing, credits, pricing, or "Go to web" surface (surfaces that only apply to Proliferate Cloud; your server's own Web app lives at your public URL), and the cloud-workspaces or model-gateway UI appears only once you configure the matching add-on. A persistent "Connected to <server>" line in the account footer identifies the server you're on, using your INSTANCE_NAME if you set one, or the connected host otherwise.

The config file

The connect dialog writes ~/.proliferate/config.json; you can also write it directly, which is the right tool for fleet provisioning and automation. The file is read once at startup.

Key	Type	Effect
`apiBaseUrl`	string	Points the app at your server instead of Proliferate Cloud.
`telemetryDisabled`	boolean	`true` turns off desktop telemetry for this install. See Telemetry & privacy.

{
  "apiBaseUrl": "https://proliferate.company.com",
  "telemetryDisabled": true
}

Changes take effect on the next app start. To switch back to Proliferate Cloud, use the reset action on the sign-in screen, or remove the apiBaseUrl line and restart.

Fleet provisioning

For MDM or fleet setups, push the same ~/.proliferate/config.json to every machine with your device management tool. Because the app reads the file at startup, installs provisioned this way connect to your server on first launch with no user action.

Planned. A shareable proliferate://connect deep link and a switch-server option in settings (without signing out) are planned. Until they ship, the sign-in screen and the config file are the supported flows.

Staying up to date

Desktop updates follow the version your server advertises. The app checks GET /desktop/updater/latest.json on your server, which redirects to the official signed update manifest for the version your server release pins. When you update the server, every connected desktop app picks up the matching version; you never manage desktop rollouts separately. See Updates & versioning.

Connect the desktop app