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, 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.

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 ./pauiops -doctor -fix -dry-run
sudo ./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";
}

sudo ./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.

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.