Deployment lifecycle
A deployment goes from your source code to a live URL in a fixed sequence. You can follow it in the dashboard, on the deployment's page, or in your terminal while hiraiship deploy runs.
Statuses
| Status | Meaning |
|---|---|
| Queued | Waiting for a free build slot. Your plan runs a fixed number of builds at once; see Build queue. |
| Building | Running on a build machine. |
| Ready | Built and published: this deployment can serve traffic. |
| Failed | The build stopped with an error, or was canceled while queued. |
A build can succeed and its publication fail; the deployment is then shown as Publish failed, with the reason. Your previous deployment keeps serving traffic.
Steps
A build goes through these steps, each timed and logged:
- Preparing: the source is fetched and unpacked on the build machine.
- Installing: your dependencies are installed.
- Building: your build command runs.
- Packaging: the output is collected and stored. Files that didn't change since the last deployment aren't stored again.
- Publish: the output goes to Cloudflare's network, behind the environment's domains.
How builds work covers what each step does.
Which deployment is live
Each environment has one current deployment, the one its domains serve.
- A successful build becomes current, unless a deployment created after it has already succeeded. Two builds that overlap never make an older version win because it finished last.
- A rollback makes an earlier successful deployment current again. The next successful build moves it forward.
A failed build changes nothing: the current deployment keeps serving traffic.
How long deployments are kept
Every deployment stays in your history. Only the most recent successful ones can be rolled back to; how many depends on your plan:
| Free | Standard | Pro | Platform | Enterprise | |
|---|---|---|---|---|---|
| Deployments kept for rollback | 3 | 30 | 100 | 5 | 500 |