Deploy PAUIOps Manager

curl -fsSL https://pauiops.kpa.ph/install.sh | sh

curl -fsSLo pauiops-install.sh https://pauiops.kpa.ph/install.sh
less pauiops-install.sh
sh pauiops-install.sh

The same command installs or updates Manager. It detects Linux AMD64, ARM64, or ARM32 and macOS Intel or Apple Silicon, inventories host dependencies, downloads the configured versioned binary, verifies SHA-256 before making changes, preserves existing configuration and data, and checks /api/ready. Linux updates use Manager’s atomic systemd upgrade path; macOS updates restore the prior binary and plist if launchd loading or readiness fails.

The installer checks installed versions before changing the host. A component at or above its compatibility floor is left alone. A missing, outdated, or non-stable component produces a detailed change plan. After approval, PAUIOps uses the operating-system or vendor stable package channel and then runs the version checks again before installing Manager.

curl -fsSL https://pauiops.kpa.ph/install.sh |
  sh -s -- --dry-run

The plan identifies repository and signing-key additions, exact package families, detected conflicting Docker packages, possible Docker or Nginx service restarts, firewall implications, Nginx module/layout differences, and potential ports 80/443 conflicts. Existing Docker data and daemon configuration are preserved. Existing Nginx configuration files are kept rather than silently replaced.

curl -fsSL https://pauiops.kpa.ph/install.sh |
  sh -s -- --yes

Automatic dependency changes support recognized Ubuntu/Debian and RHEL-family package-manager paths when their official stable repositories publish the host architecture and release. Fedora can use Docker’s stable repository, but nginx.org does not publish a Fedora stable repository. Nginx stable packages also exclude Linux ARM32. Unsupported hosts receive the inventory and stop with manual remediation instead of guessing.

curl -fsSL https://pauiops.kpa.ph/install.sh |
  sh -s -- --update --dry-run

sudo systemctl stop pauiops.service
sudo cp -a /var/lib/pauiops/pauiops.db /var/lib/pauiops/pauiops.db.before-1.1
sudo systemctl start pauiops.service

curl -fsSL https://pauiops.kpa.ph/install.sh |
  sh -s -- --update

Apart from the recommended backup window above, you do not need to stop PAUIOps manually for the update itself. The updater requires an existing managed installation, verifies the release checksum, and performs the controlled service transition. Expect only the short restart needed to load the new binary. Existing environment settings, projects, database, and application data are preserved.

sudo systemctl status pauiops.service
sudo journalctl -u pauiops.service -n 100 --no-pager

VERSION=1.1.0
curl -fsSL https://pauiops.kpa.ph/install.sh |
  sh -s -- --update --version "$VERSION"

On a first install, the script creates a protected minimum configuration. Linux stores it at /etc/pauiops/pauiops.env; macOS stores it at ~/Library/Application Support/PAUIOps/.env. Existing files are never replaced during updates.

curl -fsSL https://pauiops.kpa.ph/install.sh |
  PAUIOPS_BOOTSTRAP_ADMIN_USERNAME=operator \
  PAUIOPS_BOOTSTRAP_ADMIN_PASSWORD='<strong-one-time-password>' \
  PAUIOPS_BOOTSTRAP_ADMIN_EMAIL='<operator-email>' \
  sh

• When sudo preserves SUDO_USER, the installer recognizes the original non-root operator.
• A valid path such as /home/<username>/repos remains where it is.
• An eligible root below /root moves to /srv/pauiops/repos only when the destination is safe and empty.
• The source below /root remains as backup; rsync --delete is never used and a non-empty destination is never overwritten.
• A dedicated pauiops account is created only when appropriate, such as a direct root-account install.
• An explicit identity or existing systemd unit remains authoritative, and the service is never allowed to run as root.

curl -fsSL https://pauiops.kpa.ph/install.sh | sh

On Linux, the installer invokes Manager’s idempotent -service=enable operation with sudo only for protected system changes. It resolves service identity, Docker access, managed-root permissions, the protected environment, systemd unit, and active-state report. On macOS, it installs a per-user launchd agent so Manager runs as the user who owns Docker Desktop and the project files.

pauiops --service status
curl -s http://127.0.0.1:51800/api/health
curl -s http://127.0.0.1:51800/api/ready
curl -s http://127.0.0.1:51800/api/version

Enabled: enabled
Active:  active

/api/health returns 503 until startup validation completes and during graceful draining; a 200 response may still show Docker or Dashboard privilege as degraded. /api/ready is the cheap database-backed readiness probe. /api/version always returns version and timestamp for liveness and release confirmation.

pauiops -doctor
pauiops -doctor -output=json
pauiops -check
pauiops -check -output=json
sudo /usr/local/bin/pauiops -doctor -fix -dry-run
sudo /usr/local/bin/pauiops -doctor -fix

Doctor reports PASS, WARNING, FAIL, FIXED, or SKIPPED across configuration, identity, root access, Git, Docker, sudo, systemd, disk, and database. Disk is FAIL below 256 MiB free and WARNING below 1 GiB. Warnings do not fail the command; any FAIL returns exit code 1.

• Use HTTPS for public access and wss:// for WebSockets behind an HTTPS Center.
• Enable PAUIOPS_TRUST_PROXY_HEADERS only behind a controlled proxy that replaces untrusted forwarded headers.
• Set PAUIOPS_ALLOWED_ORIGINS to the exact Center origin; never use * in production.
• PAUIOPS_SECURE_COOKIE=1 forces Secure cookies only when the browser actually uses HTTPS.
• Restrict firewall access to trusted networks or a secure access layer whenever possible.

location / {
  proxy_pass http://127.0.0.1:51800;
  proxy_http_version 1.1;
  proxy_set_header Host $host;
  proxy_set_header X-Forwarded-Proto https;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "upgrade";
}

The URL installer’s default Linux destination is /usr/local/bin/pauiops. You can use either the full-path command or the shorter PATH command shown for every action. The full path works independently of shell PATH configuration; sudo pauiops works when /usr/local/bin is included in sudo’s PATH, as it normally is. Status is read-only and does not require sudo. If PAUIOPS_MANAGER_INSTALL_PATH is customized, use that configured path instead.

sudo /usr/local/bin/pauiops -repair-permissions

Permission repair covers the managed project tree and writable Git metadata while skipping dependency/build trees such as node_modules, vendor, dist, build, and .next. Never use chmod 777.

sudo /usr/local/bin/pauiops -service=uninstall
# Optional: remove the default executable after the service is gone.
sudo rm -f /usr/local/bin/pauiops

The first Linux command stops and disables pauiops.service, removes its systemd unit, reloads systemd, and preserves the executable. Run the second line only when you also want to remove the default executable. If PAUIOPS_MANAGER_INSTALL_PATH or PAUIOPS_SYSTEMD_UNIT_PATH is customized in /etc/pauiops/pauiops.env, use those configured paths instead.

launch_uid="$(id -u)"
launch_label="ph.kpa.pauiops"
launch_plist="$HOME/Library/LaunchAgents/$launch_label.plist"

launchctl bootout "gui/$launch_uid/$launch_label" 2>/dev/null || \
  launchctl bootout "gui/$launch_uid" "$launch_plist" 2>/dev/null || \
  launchctl bootout "user/$launch_uid/$launch_label" 2>/dev/null || \
  launchctl unload "$launch_plist" 2>/dev/null || true
rm -f "$launch_plist" "$HOME/.local/bin/pauiops"

Service, repair, doctor, check, and upgrade modes are one-shot operations and never start the HTTP server. Service actions return 0 success, 1 failure, 2 invalid action, 3 unsupported platform, or 4 root required. Diagnostics return 1 only when a check fails. Upgrade returns 0 for success or identical no-op, 1 for validation/install/health failure, 3 off Linux, and 4 without root.

sudo /usr/local/bin/pauiops -upgrade=/tmp/pauiops-new

Linux and root are required. The candidate must be a non-empty executable ELF matching the host architecture. Manager compares checksums, treats an identical binary as a successful no-op, keeps <install-path>.backup, swaps atomically, restarts systemd, and optionally requires the configured health URL to return 2xx. If health fails, it restores and restarts the previous binary; the upgrade still exits non-zero.

On SIGTERM, Manager stops readiness, drains HTTP work for PAUIOPS_SHUTDOWN_TIMEOUT (25s by default), closes the database, and exits before the generated unit’s TimeoutStopSec=30 hard stop.