Deploy, health check, and rollback

A deployment builds a candidate first; it does not replace healthy traffic early.

Before creating a release

  • The repository must have synced successfully.
  • Save at least one project environment value.
  • On an actual host, save at least one project domain so the helper can activate Nginx and TLS.
  • For Docker Compose, install Docker Engine and Compose through Setup before syncing the project.

Native candidate phases

  1. Portal copies the selected repository directory into a candidate release.
  2. Node uses npm ci for a valid package-lock.json; Bun uses bun install --frozen-lockfile for a compatible Bun lockfile. Missing or incompatible locks fall back only inside the isolated candidate to an unlocked install.
  3. The optional named build script runs unless Skip Build was selected.
  4. The required named start script launches the candidate. If enabled, Portal probes the configured HTTP path before host activation.

Activation and jobs

Host-mode deployments are queued durably, so a dashboard restart does not lose their job state. The helper starts the service, repeats the bounded host health check, then applies managed domains/TLS. The release log records candidate preparation, dependency choice, build, health, activation, and safe failure reason; it deliberately does not retain secret-bearing command output.

Rollback

Use the project’s Actions → Rollback to activate the previous eligible release. Portal refuses competing deploy/rollback work for the same project. If a candidate or activation fails, the active release remains unchanged; inspect Logs before retrying.

Last audited: 2026-08-25
Portal source of truth