Deployment & Promotion

Deploys can be triggered three ways: a GitHub push (webhook auto-deploy), the dashboard Deploy button, or the REST API. Builds promote across environments without rebuilding.

Webhook auto-deploy

With the GitHub App installed, pushes to a project's configured branch are verified via X-Hub-Signature-256 and enqueued as deploy jobs automatically. Pushes to other branches are ignored.

Manual deploy via API

# Create a project
curl -X POST http://localhost:9090/api/v1/projects \
  -H 'Content-Type: application/json' \
  -d '{ "name": "myapp", "repoUrl": "https://github.com/you/myapp", "branch": "main", "appPort": 3000 }'

# Trigger a deploy
curl -X POST http://localhost:9090/api/v1/deploy \
  -H 'Content-Type: application/json' \
  -d '{ "projectId": "<id>" }'

Promote without rebuilding

Promotion reuses the Docker image tag from the source environment's active deployment — the exact artifact verified in staging is what production runs. The build and git-pull steps are skipped entirely; only container start, health check, and traffic switch execute.

POST /api/v1/projects/:id/environments/:envId/promote
{ "sourceEnvironmentId": "<staging-env-id>" }

The dashboard's project page renders the environment chain with a Promote button per stage, disabled until the upstream environment has an active deployment.

Rollback

POST /api/v1/projects/:id/rollback

Rollback restarts the previous ROLLED_BACK deployment's image on its original port, health-checks it, then switches Nginx back. If the health check fails, the current deployment stays live — rollback never makes things worse.