Deployments
A deployment is one build of one commit. Each push to a connected repository creates one, and so does every deploy hook call and every press of the Deploy button.
Production and preview#
Every app has a production branch, set when you create it and changeable under Settings → Source. What a push does depends on the branch:
| You push to | Result | Address |
|---|---|---|
| The production branch | A production deployment. When it is ready, your app's address and any custom domains serve it. | https://v2-<app-name>.ahurasense.com |
| Any other branch | A preview deployment of that branch, with its own address. Production is never touched. | https://<app-name>-<branch>-<id>.ahurasense.com |
Preview deployments always run at the Starter size with one instance, whatever size the app uses in production. A preview keeps its address across pushes to the same branch. Deleting the branch does not remove its preview.
To stop pushes to the production branch from deploying — so that production only updates from your CI — turn off Deploy on every push. Previews keep deploying. See Deploy hooks.
What does not deploy
- Pushing a tag, or deleting a branch.
- Pushing a commit that has already been deployed to the same branch. It is recognised and not built twice.
- A repository connected to more than one app. Connect each repository to one app.
The lifecycle of a deployment#
| State | What is happening |
|---|---|
queued | Waiting for a build machine. Deployments build in the order they arrived. |
building | Your code is being fetched and built into a container image. The build log streams on the deployment's page. |
publishing | The image is stored, your app's address is routed to it, and the new version is starting. |
ready | The new version is running and has answered our health check. It is serving. |
error | It failed. The deployment shows the reason; see Errors. |
A deployment is only marked ready once it is actually serving — its container has started and is accepting connections on its port. Most deployments take between four and nine minutes from push to ready, most of it in the build. A build is stopped if it runs longer than 20 minutes.
A push received while builds are paused — during maintenance, for example — is not lost. It waits in the queue and builds when they resume.
When a deployment fails#
If the build fails, nothing changes: the previous version keeps serving and the deployment shows why it failed, with the full build log.
If it builds but the app does not start — it crashes on boot, or never listens on its port — the deployment fails with rollout_failed after four minutes. By then your app’s address has already moved to the new version, so roll back to serve the previous one, then check Runtime logs for what the app printed as it exited.
Logs#
Build log
Open the Deployments tab and choose a deployment. Its build log shows the detected framework, the generated Dockerfile when we wrote one, and everything your install and build commands printed.
Runtime logs
The Runtime logs tab shows what your running app writes to standard output and standard error, per instance. If an instance has restarted, the logs from the run that failed are shown and marked as the previous run, because that is where the error is.
Rollback#
Rollback serves an earlier production deployment again, instantly and without rebuilding: the image it built is kept.
- On the app’s Overview, under Serving, open Rollback available and choose a deployment.
- Choose Serve this. Your app’s address and custom domains move to it.
Only production deployments that reached ready can be rolled back to. A rolled-back version runs with the app’s current environment variables, not the ones it was built with — except public variables, which are part of its build. Your next production deploy moves the app forward again.
Something missing or wrong on this page? Tell us, and quote the page title.