Docker on any server

Every self-hosted Proliferate runs the same Docker Compose stack, shipped as a deploy bundle with each server release. The cloud guides (AWS, GCP, Azure) are just ways of getting a host that runs this page. Everything here applies to all of them.

What you get

Four Compose services in a base install:

• caddy terminates HTTPS with automatic certificates for your domain and proxies everything to the api service
• db is Postgres 16, the only stateful service
• migrate is a one-shot container that runs database migrations
• api is the Proliferate server, from ghcr.io/proliferate-ai/proliferate-server. It answers the API and, by default, also serves the compiled Web app: the server image bakes in the built ProductClient Web distribution, and WEB_DIST_DIR in the shipped Compose file points at it, so one public URL serves both a browser and the desktop app. No separate Web container and no Node process run at runtime.

Two more optional service groups exist in the same Compose file, off by default and turned on automatically by your configuration (see Compose profiles for optional services below): litellm + litellm-db for the model gateway, and redis for the cloud sandboxes add-on (coming soon).

Deploy

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

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

curl -fsS https://proliferate.company.com/health
curl -fsS https://proliferate.company.com/meta

Manual setup

curl -fsSL https://github.com/proliferate-ai/proliferate/releases/download/server-vX.Y.Z/proliferate-deploy.tar.gz -o proliferate-deploy.tar.gz
curl -fsSL https://github.com/proliferate-ai/proliferate/releases/download/server-vX.Y.Z/self-hosted-assets.SHA256SUMS -o self-hosted-assets.SHA256SUMS
sha256sum -c --ignore-missing self-hosted-assets.SHA256SUMS
tar xzf proliferate-deploy.tar.gz && cd proliferate-deploy && cp .env.production.example .env.static

# .env.static
SITE_ADDRESS=proliferate.company.com
PROLIFERATE_TELEMETRY_MODE=self_managed
PROLIFERATE_SERVER_IMAGE_TAG=X.Y.Z
 
# Leave blank: bootstrap generates and persists these
JWT_SECRET=
CLOUD_SECRET_KEY=
POSTGRES_PASSWORD=

./bootstrap.sh

First-run setup is pending. Claim this instance in a browser:

  Setup token: 7f3a...c91b
  Claim URL:   https://proliferate.company.com/setup

What bootstrap actually does

bootstrap.sh is a thin orchestrator over the scripts in the bundle:

1. ensure-secrets.sh merges .env.static with optional .env.local overrides, generates any blank secrets, derives API_BASE_URL and the public health check URL from SITE_ADDRESS when you have not set them (explicit values win), and writes two files: .env.generated (the secrets of record, mode 600) and .env.runtime (the merged file Compose actually reads, regenerated on every run).
2. preflight.sh validates the resolved .env.runtime and refuses to proceed on a dangerous partial config (see the callout above), before any docker compose lifecycle command runs.
3. registry-login.sh is a no-op for ghcr.io; it logs Docker into a private ECR registry when PROLIFERATE_SERVER_IMAGE points at one.
4. install-runtime.sh downloads and checksum-verifies the runtime binaries into /opt/proliferate/bin when the CLOUD_*_SOURCE_BINARY_PATH variables are set. A base install skips this; the variables belong to the cloud sandboxes add-on (coming soon).
5. Compose: up -d db, then run --rm migrate, then up -d api caddy.
6. Compose profiles: brings up and waits for any optional services your config enables (below), then
7. wait-for-health.sh polls http://127.0.0.1:8000/health, then the public https://<SITE_ADDRESS>/health, then prints the setup token and claim URL while the instance is unclaimed.

The env files, at a glance:

Compose profiles for optional services

Two capabilities are wired to a Compose profile, computed automatically from your config by bootstrap.sh and update.sh — there is no separate docker compose --profile ... command to run for either:

When one of these is enabled, bootstrap/update pull, start, and wait for the matching services to report healthy before handing back control. A base install with neither capability configured never pulls or starts them.

Local evaluation

Bring your own certificate

The shipped Caddyfile always reserves a /llm path for the model gateway add-on ahead of the default site handler — harmless when the gateway is off, since there is simply no litellm host to resolve:

{$SITE_ADDRESS} {
  encode zstd gzip

  handle_path /llm/* {
    reverse_proxy litellm:4000
  }

  handle {
    reverse_proxy api:8000
  }
}

By default Caddy provisions publicly trusted certificates automatically, which requires public DNS and reachable ports 80/443. If your host cannot do that (internal network, corporate CA), add a tls directive pointing at your own certificate, keeping the rest of the file intact:

{$SITE_ADDRESS} {
  encode zstd gzip
  tls /certs/server.crt /certs/server.key

  handle_path /llm/* {
    reverse_proxy litellm:4000
  }

  handle {
    reverse_proxy api:8000
  }
}

Mount the certificate directory into the caddy service in docker-compose.production.yml (for example ./certs:/certs:ro). If the certificate comes from an internal CA, every machine running the desktop app must trust that CA.

Updating

./update.sh

update.sh pulls the pinned image, reruns migrations, and restarts the stack (pull, run --rm migrate, up -d), including any optional-profile services your config enables (the model gateway, cloud-workspaces Redis) — the same mechanism bootstrap uses, so there is nothing extra to run for those. To move to a new release, set PROLIFERATE_SERVER_IMAGE_TAG in .env.static and run it. Connected desktop apps follow the version your server advertises, so updating the server updates the fleet. See Updates & versioning.

Next steps

• Invite your team: an admin invites an email and shares the invite link, and the invitee creates their account in a browser. No email provider required.
• Model gateway
• Updates & versioning
• Troubleshoot