Skip to content

Automated installer (install.sh)

The repository ships an interactive installer — a wizard over the same docker-compose.yml a manual install uses. It writes .env, generates secrets, and brings the stack up; it does not install Docker itself (see Installation overview for the prerequisites).

./install.sh            # menu
./install.sh --dry-run  # print every mutating command, execute nothing
./install.sh -h         # help

The UI is whiptail dialogs (installed on demand when apt is available). On a minimal host or over a plain serial console, force the plain-text fallback:

UMBRYX_INSTALL_NO_TUI=1 ./install.sh

Modes

The installer builds exactly one menu entry — everything else below is planned, not shipped:

Mode Edition Status What it does
aio Core, EE shipped Single-node "all-in-one": writes .env, docker compose build && up for db/redis/backend/frontend/nginx on this host
ha_seed EE not shipped First HA node: pg_auto_failover monitor, this node's Postgres, HAProxy + keepalived (VIP), Redis + Sentinel
ha_join EE not shipped Second (or later) node joining an existing HA cluster
ha_app EE not shipped Point this node's app layer (backend/frontend/nginx) at a running HA cluster through its VIP

HA is deployed today via docker-compose.ha.yml by hand — follow HA deployment; that page remains the source of truth.

What the aio mode asks and does

  1. Checks prerequisites — docker, openssl, curl must be on the host.
  2. Database — Postgres username, database name, password.
  3. Admin account — initial admin username and password (change it after first login).
  4. Network — the port nginx exposes the platform on (default 3000).
  5. Environment — production (recommended: enforces ENCRYPTION_KEY, stricter defaults) or dev (relaxed checks, local testing only).
  6. HTTPS — in production mode: is the instance reachable over HTTPS? Answers No if you are only testing over plain HTTP — otherwise login cookies would require HTTPS and lock you out (COOKIE_SECURE).
  7. Generates secrets — JWT_SECRET and WEBHOOK_HMAC_SECRET (random hex-32), ENCRYPTION_KEY (Fernet key). Secrets are typed into masked prompts and never echoed or logged.
  8. Writes .env — an existing .env is backed up first, never overwritten in place.
  9. Builds and starts the stack, then waits for the first-login screen (/api/auth/setup) to answer.

The result is byte-for-byte what a manual Core installation produces — the installer is only the wizard over the same compose file.

HA modes: read before running

  • pg_auto_failover node registration is a one-shot handshake. Re-running ha_seed/ha_join against an already-bootstrapped cluster is not safe.
  • Prerequisite on every HA host: sudo sysctl -w net.ipv4.ip_nonlocal_bind=1 (the installer offers to run it).
  • ENCRYPTION_KEY and JWT_SECRET must be byte-for-byte identical on every app node — generate once on the seed node and reuse the values everywhere.

Full topology, recovery and teardown: HA deployment.

Safety notes

  • --dry-run prints every mutating command instead of running it — review a mode on the real host before committing to it.
  • Cancel any dialog and the installer stops; nothing is half-applied except what the completed steps already did (.env backup keeps the previous state recoverable).
  • The installer never starts, stops or reads the live stack's data directory — it only manages this checkout's compose project.

After the install: Verification — health checks and first login.