5. Ship a change, and roll it back
Deploy a new version behind the health check, put the previous one back in seconds, and deploy on every push.
Goal: deploy a new version of your application, put the previous one back in seconds, and have every push deploy by itself.
Time: five minutes.
You need: a deployed application and a commit pushed to the branch it follows.
The examples use Kelmoor's application wrenfield.io, whose last commit is a1c4f92, "Rework the
homepage hero section".
How it works
Each deploy builds a new release next to the one that serves. Noust starts it and asks it for an answer, its health check. Only when it answers does traffic move to it; if it does not, the release that was serving keeps serving and the deploy fails with the probes and the application's log. The previous releases stay on disk, so going back rebuilds nothing. How Noust works has the details.
Steps
-
Deploy the new commit.
Shellnoust update wrenfield.ioNoust fetches the branch, builds the commit in a new release, and switches to it once it answers. In the console: the application's page, Update.
-
See the releases.
Shellnoust releases list wrenfield.ioThe newest is first, and the one that serves has a
*. -
Go back to the previous one.
Shellnoust releases rollback wrenfield.ioNoust restarts the application on the release before the active one and keeps it only if it answers. It takes seconds: nothing is built. In the console: Roll back, on the application's page.
-
Serve any other release on disk.
noust releases rollbacktakes a release's id, newer or older than the one that serves:Shellnoust releases rollback wrenfield.io 20261029-181502-a1c4f92When the fix is ready, push it and run
noust update wrenfield.ioagain. -
Deploy on every push. Your Git host has to reach the server, and the console listens only on
127.0.0.1. Give webhooks a public name of their own, once per server: it forwards/hooks/to the console and answers nothing else. Point the name at the server first, as in Put it on your domain:Shellnoust web expose-hooks hooks.kelmoor.devFor a GitHub repository, then connect the GitHub App (Settings > Integrations). For any other Git host, create the application's webhook:
Shellnoust app webhook rotate wrenfield.ioIt prints the secret, the payload URL, the events to enable and where to add them on the Git host.
noust app webhook show wrenfield.iosays later how far it is set up. In the console: the application's Settings > Deploy on push. A push that arrives while a build runs waits its turn; several pushes become one update.
What you should see
noust releases list wrenfield.io shows a table, newest first: each release's id (the time it was
built and its commit, 20261029-181502-a1c4f92), the commit, its status (active, superseded,
rolled_back, failed, or built for one built and never served) and when it last served. The one
that serves is marked *.
noust releases rollback wrenfield.io ends with:
Rolled back to release 20261022-093011-5e9d0b3 of wrenfield.io
The database was left as it is: going back puts code back, never data.
Release 20261029-181502-a1c4f92 stays on disk: noust releases rollback wrenfield.io 20261029-181502-a1c4f92The application's Deployments tab in the console keeps every build's log, the failed ones included.
If it fails
- The new release did not answer: nothing changed for visitors. The error has the probes and the last lines of the application's log. Read them, fix the commit and deploy again. A build or a deploy failed.
- The rollback is refused because a deploy changed the database schema: a hook marked
migrates: trueran since that release (Give it a database). The older code may not work with the newer schema, so Noust asks you to say it does:noust releases rollback wrenfield.io --schema-changed-ok. It still puts back only the code. noust releases listsays the application has no releases: it is deployed in place (an older application, or one created with--layout inplace).noust rollback wrenfield.iorestores its last backup instead, or move it to releases withnoust app migrate(Release, roll back and migrate).