Skip to main content
A deployment record is created automatically when a build passes and the project has no sensitive environment variables that would prevent static serving. Each deployment is linked to the build that produced it and carries a status of either live or rolled_back. These two endpoints let you inspect a deployment’s current state and roll back to an earlier one when needed.

GET /api/deploy/deployments/:deploymentId

Fetches a single deployment record by ID. The server verifies that the deployment’s build belongs to a project owned by the authenticated user before responding. Requires JWT.

Path parameters

number
required
Numeric ID of the deployment to fetch. Deployment IDs appear in the deployment field nested inside each build in the GET /api/project/projects response.

Curl example

Response

Response fields

object
The deployment record, with the associated build nested inside.
number
Unique deployment ID.
string
Current deployment status. One of live or rolled_back.
number
ID of the build that produced this deployment.
string
ISO 8601 timestamp of when the deployment record was created.
object
The build record linked to this deployment. See GET /api/build/:buildId for a full description of build fields.

Error responses


PUT /api/deploy/rollback

Rolls back to a previous deployment by re-running the full build pipeline from that deployment’s original commit hash. The current live deployment is marked as rolled_back, a new build record is created and queued, and the pipeline runs asynchronously in the background. Requires JWT.
Rollback triggers a full rebuild — Shipyard clones the repository at the previous commit hash, runs the install and build commands inside a Docker container, and deploys the output if the build passes. It is not a file restore or a swap of static assets; the entire CI pipeline executes again.

Query parameters

number
required
ID of the current live deployment to mark as rolled back.
number
required
ID of the previous deployment to roll back to. Shipyard reads the commit hash from this deployment’s associated build and uses it to create the new build.

Curl example

Response

The server responds immediately with the new queued build. The rebuild pipeline runs asynchronously after the response is sent.

Response fields

object
The newly created build record that will produce the rolled-back deployment.
number
ID of the new build. Use this to monitor rollback progress via buildStatusUpdate Socket.io events.
string
Always queued immediately after the rollback is initiated.
string
The commit hash from the previous deployment’s build — the exact code that will be checked out and built.

Error responses