Deployments API
Trigger builds, deploy from git or an uploaded folder, then inspect, redeploy, roll back, and manage the lifecycle of a project's releases.
The Deployments API drives a project's build-and-release lifecycle: it starts builds (from a linked git
repo or an uploaded folder), reports status and logs, and handles the operations you run afterwards —
redeploy, roll back, pin, cancel, restart, and resolve a partial-failure compose deploy. In the dashboard
this is the deploy wizard and the Deployments tab; from the terminal it's alaf server deploy
and alaf server deployment.
Base path & auth
All paths are relative to your instance, under /api — e.g. https://your-host/api/deployments.
Send a personal access token as a bearer header (Authorization: Bearer <token>), created with
alaf server token create. The dashboard uses your session cookie instead. See the
API overview and auth model for details.
Available on self-hosted and cloud
This module is mounted on every instance. When a deployment belongs to a cloud project, the
per-deployment routes (/:id/...) transparently proxy to Alaf Server Cloud; local deployments are handled
in place. You use the same paths either way.
Endpoints
| Method & path | Permission | What it does |
|---|---|---|
GET /api/deployments | deployment:list | List deployments in the org (optionally filter with ?projectId=). |
POST /api/deployments | deployment:write | Git-based deploy — redeploy an already-linked project from its git source. |
POST /api/deployments/prepare | deployment:write | Detect stack / build config for a git repo or local path before deploying. |
POST /api/deployments/build/access | deployment:write | The wizard Deploy action — starts the build + deployment (git or folder upload). |
POST /api/deployments/ssl/status | deployment:read | Check a domain's SSL certificate status (side-effect-free). |
POST /api/deployments/ssl/renew | deployment:write | Renew a domain's SSL certificate. |
GET /api/deployments/:id | deployment:read | Get a deployment by id — status, URLs, timing, error summary. |
GET /api/deployments/:id/logs | deployment:read | Fetch a deployment's build / runtime logs. |
GET /api/deployments/:id/stream | deployment:read | Stream build / deploy logs and events live (SSE). |
GET /api/deployments/:id/build | deployment:read | Get the build-session status for this deployment. |
POST /api/deployments/:id/build | deployment:write | Start the build for a queued deployment (then streams logs via SSE). |
POST /api/deployments/:id/build/respond | deployment:write | Respond to a build gate / prompt (e.g. approve a step). |
POST /api/deployments/:id/redeploy | deployment:write | Re-run the latest deployment for this project. |
POST /api/deployments/:id/rollback | deployment:write | Roll back to this deployment's artifact / commit. |
POST /api/deployments/:id/pin | deployment:write | Pin (or unpin) this deployment so cleanup won't reclaim it. |
POST /api/deployments/:id/cancel | deployment:write | Cancel an in-progress deployment. |
POST /api/deployments/:id/keep | deployment:write | Keep a partial-failure deployment awaiting a decision (accept the succeeded services). |
POST /api/deployments/:id/reject | deployment:write | Reject a partial-failure deployment awaiting a decision (roll back the changed services). |
POST /api/deployments/:id/restart | deployment:write | Restart the running container(s) for this deployment. |
GET /api/deployments/:id/info | deployment:read | Get container info for this deployment. |
GET /api/deployments/:id/usage | deployment:read | Get container CPU / memory usage for this deployment. |
DELETE /api/deployments/:id | deployment:admin | Delete a deployment. |
rollback and cancel need admin at runtime
Their route tag is deployment:write, but the handlers additionally assert deployment:admin on the
target deployment (a rollback re-clones the repo). A caller with only write will pass the route check
and then be denied. Grant deployment:admin for these two operations.
Trigger a git deploy
Redeploys an already-linked project from its git source. To deploy a local folder instead, use the
upload flow that ends at /build/access.
POST /api/deploymentsProp
Type
curl -X POST https://your-host/api/deployments \
-H "Authorization: Bearer $ALAFSERVER_TOKEN" \
-H "Content-Type: application/json" \
-d '{"projectId":"proj_123","branch":"main"}'# Same thing from the CLI:
alaf server deploy --project proj_123 --branch mainPrepare (detect build config)
Side-effect-free: point it at a git repo or a local path and it returns the detected framework, package manager, and build/start commands so the wizard can pre-fill. Creates nothing.
POST /api/deployments/prepareProp
Type
Local source is self-hosted only
source: "local" is rejected with 403 in cloud mode — cloud has no host filesystem to read.
Deploy wizard (/build/access)
The wizard's Deploy button. Creates a fresh deployment and starts the build. For a folder-upload
deploy, pass projectId (from projects/ensure) and uploadSessionId (from projects/folder/session);
for a git project, pass projectId and optionally branch. Returns { success, deployment_id, project_id }.
POST /api/deployments/build/accessProp
Type
Each publicEndpoints entry is { port?, targetPath?, domain?, customDomain?, domainType? } where
domainType is "free" or "custom". A services entry mirrors a compose/monorepo service
(name, image?, build?, dockerfile?, ports, dependsOn, environment, volumes, and the
optional per-app build fields).
curl -X POST https://your-host/api/deployments/build/access \
-H "Authorization: Bearer $ALAFSERVER_TOKEN" \
-H "Content-Type: application/json" \
-d '{"projectId":"proj_123","branch":"main","buildStrategy":"server"}'Don't force deployTarget on self-hosted
Setting deployTarget: "cloud" on a self-hosted instance triggers a promote-to-cloud flow. For a normal
folder upload, leave deployTarget unset and let the upload session's mode decide.
Get status, logs, and stream
GET /api/deployments/:id
GET /api/deployments/:id/logs
GET /api/deployments/:id/stream/:id returns the deployment's status, URLs, timing, and any error summary. /logs returns the recorded
build/runtime output; /stream is a Server-Sent Events feed of the live build — reconnect to it with a
?since=<seq> cursor to resume where you left off.
alaf server deployment get <deploymentId>Redeploy
Re-runs the build. By default it resolves the latest commit on the branch (the auto-redeploy semantic);
send { "useExistingCommit": true } to rebuild against the exact commit the original deployment used.
POST /api/deployments/:id/redeployalaf server deployment redeploy <deploymentId>Rollback and pin
Rollback restores a previous deployment's artifact/commit as the active release. Pinning marks a
deployment as protected so it isn't reclaimed by the rollback-window cleanup — POST /:id/pin defaults to
{ "pinned": true }; send { "pinned": false } to unpin.
POST /api/deployments/:id/rollback
POST /api/deployments/:id/pinalaf server deployment rollback <deploymentId>
alaf server deployment pin <deploymentId>Cancel a running deploy
POST /api/deployments/:id/cancelalaf server deployment cancel <deploymentId>Partial-failure compose deploys: keep or reject
When a multi-service (compose) deploy has some services succeed and others fail, it is held in
partial_failure with decision: pending ("Action Required"). Resolve it explicitly:
- Keep accepts the services that succeeded and leaves the rest on their prior version.
- Reject rolls back the changed services to their previous state.
POST /api/deployments/:id/keep
POST /api/deployments/:id/rejectalaf server deployment keep <deploymentId>
alaf server deployment reject <deploymentId>SSL status and renew
Both take the domain in the JSON body. /ssl/status is a side-effect-free probe (POST only so the
hostname travels in the body); /ssl/renew re-issues the certificate.
POST /api/deployments/ssl/status
POST /api/deployments/ssl/renewProp
Type
curl -X POST https://your-host/api/deployments/ssl/status \
-H "Authorization: Bearer $ALAFSERVER_TOKEN" \
-H "Content-Type: application/json" \
-d '{"domain":"app.example.com"}'alaf server deployment ssl status app.example.com
alaf server deployment ssl renew app.example.comErrors you might see
400 — bad request / failed operation
Missing a required field (domain is required, source must be 'github' or 'local') or the operation
couldn't run (e.g. cancelling a deployment that already finished, or keep/reject on a deployment that
isn't awaiting a decision). The response body carries { success: false, error }.
403 — local source in cloud mode
prepare with source: "local" (or a folder deploy) isn't available on Alaf Server Cloud — there's no host
filesystem. Use a git source instead.
404 on a per-deployment route
The :id doesn't belong to your organization (or was deleted). List with GET /api/deployments to get
valid IDs.
Projects API
Create and configure projects, link a git repo, manage env vars and resources, read logs, deploy an uploaded folder, and transfer projects to and from Alaf Server Cloud.
Services API
Manage the services inside a project — compose services and monorepo sub-apps — including CRUD, sync from compose, container actions, drift resolution, and env vars.