Deploying and rolling back
Deploying#
Open the project and hit Deploy. CloudPilot puts the new release into its own directory on the server and then points the live path at it.
Two consequences of that design:
- The switch is quick, because it is a pointer change rather than a copy over the top of a running app.
- The previous release is still on disk, which is what makes rollback possible without rebuilding anything.
If the project is protected, the deploy is not carried out immediately — it is queued as a change request for someone else to approve.
Watching a deploy#
The deploy log streams as it runs. When something fails, the error is in that log; read it before retrying, because the same deploy will usually fail the same way twice.
Rolling back#
Open the project's deployment history, pick the release you want, and roll back to it. CloudPilot repoints the live path at that release.
Rollback is a deploy of a known-good release, so:
- It is subject to the same approval rules on a protected project.
- It is recorded in the audit log like any other deploy.
Repointing the code is not the same as undoing what the code did. If the release you are rolling back from ran a database migration, rolling the code back leaves the migrated database in place. Plan migrations so that the previous release can still run against the new schema, or be ready to restore from a backup.
Deploying automatically from GitHub#
A project can be given a webhook so that a push deploys it. On a protected project this still goes through approval — the push creates the request rather than the release.
See Auto-deploy from GitHub for the setup and for what to check when a push does not deploy.
Restarting without deploying#
If the application is misbehaving but the code is fine, Restart is the smaller hammer. It does not change which release is live and does not require approval, because nothing is replaced or removed.
Raise a ticket and someone will pick it up. Sign in with the same account you use for the panel.
Raise a ticket