Deploys
Auto-deploy, manual deploys, restarts, rollbacks and cancelling a deploy.
A deploy builds a commit and replaces the running version of your web service with it. You follow and control deploys from the service's Events page.
Auto-deploy
With Auto-deploy on, every push to the service's branch deploys that exact commit. Auto-deploy is on for new services. Turn it off or on in the service's Settings, under Build & Deploy. The change saves straight away.
A push doesn't deploy a suspended service.
If you push again while a deploy is still queued or building, the newer deploy replaces it.
The Events page
The Events page lists what happened to the service, newest first. Each deploy shows its commit and message, and a failed one shows the reason under it. The page updates by itself while a deploy runs.
| Label | Meaning |
|---|---|
| Queued | The deploy is waiting to start. |
| Building | The build is running. |
| Release | The release command is running or has finished. |
| Deploying | The new version is starting. |
| Live | The deploy, rollback or restart succeeded. |
| Failed | The build or deploy failed. |
| Cancelled | The deploy was cancelled, or replaced by a newer one. |
| Setup | A Feather app's one-step setup is running or has finished. |
| Created | The service was created. |
| Suspended, Resumed | You suspended or resumed the service. |
| Domain | A custom domain was added, verified, activated or removed. |
| Deleting | The service is being deleted. |
| Update | Anything else, such as the app crashing or recovering, or a new appentic.app address. |
Deploy manually
Any of these builds and deploys the latest commit on the branch:
- On the Events page, click Manual deploy on the current live deploy.
- After a failed deploy, click Deploy on the failed entry.
- In Settings → Build & Deploy, open the menu next to Save only and choose Deploy latest commit.
Save & Deploy in the same menu saves your changes to the build settings, then deploys.
To rebuild without the cache, choose Clear build cache & deploy from the same menu. See Build cache.
Restart
In Settings → Build & Deploy, open the menu and choose Restart service. This starts the current version again without rebuilding, with the latest environment variables, usually in under a minute. Use it when your app is stuck.
Appentic restarts a service by itself when something it reads at start-up changes: an environment variable, a new custom domain, or a new appentic.app address.
Roll back
Recent live deploys on the Events page have a Rollback button. Click it and confirm to put that version back. A rollback reuses that deploy's build, so nothing is rebuilt. Appentic keeps the builds of the six most recent deploys (restarts and rollbacks count towards the six), so you can roll back to any of those that went live.
A rollback doesn't change your repository or turn off Auto-deploy, so the next push deploys the branch again.
Cancel a deploy
While a deploy is queued or building, the newest entry on the Events page shows a spinner and a Cancel button. Click Cancel and confirm to stop it. The version that was live keeps running.
Once the new version has started rolling out, the deploy can't be cancelled.
How a deploy goes live
After the build (and the release command, if you set one), the new version starts. It takes traffic as soon as it's ready: when it accepts connections, or when its health check path answers.
The deploy fails, and the version that was live keeps running, when the new version:
- keeps stopping as it starts. The Events page shows the last error from its logs.
- runs out of memory.
- isn't ready within 5 minutes.
Zero-downtime deploys
How a new version replaces the old one depends on the memory not yet guaranteed to any service on the web service's machine:
- Room for a second copy of its guaranteed memory. The new version starts next to the old one. Traffic moves to it once it is ready, and then the old version stops. Visitors notice nothing.
- Not enough. The old version stops first and the new one starts in its place. The service is offline until the new version is ready, usually a few seconds. With the back-soon page on, visitors see it during the gap.
To get zero-downtime deploys, keep at least as much memory unguaranteed on the machine as the web service's guaranteed memory. The Resources page names each web service that will go offline during an update. See What a machine card shows.
Restarts and rollbacks replace the running version the same way.
When you can't deploy
Deploys, restarts and rollbacks are refused while the service is suspended or being deleted, and while its machine is stopped or the project is suspended. A restart is also refused while any deploy is in progress, and a rollback while another version is rolling out. A message tells you why.