Deploys, previews and rollbacks.
How pushes go live, branch previews, going back to an earlier version, the release command for migrations, build settings, deploy hooks, maintenance mode and preview passwords.
Once an application is live, you rarely need the panel to ship changes: push to the branch and the new version goes live by itself. This article covers everything around that — the Deploys tab, Previews, the Processes tab and a few switches in Settings.
Automatic deploys on every push
Every push to the application's branch builds the latest commit and deploys it. The new version starts next to the running one and receives visitors only once it answers; if it doesn't start, the previous version keeps running and we let you know by email (and Telegram, if you have connected it).
A push made while another build is still waiting in the queue joins that build, so a burst of pushes doesn't create a long queue.
You can turn this off in Settings → Deploy every push. With it off, you deploy from the panel, the API or a deploy hook.
Deploying from the panel
The Deploys tab lists every deploy: what started it (a push, the panel, a rollback, a deploy hook), the commit, how long it took and its status. Click a deploy to see its full build log.
Redeploy offers two choices:
- Build the latest commit — takes the newest code from the branch and builds it.
- Deploy the running version again — applies changed variables, without a new build. Use it after editing Variables.
The menu next to Open has the same two actions plus Restart.
Rolling back
You can go back to any of the last 5 successful versions. On the Deploys tab, click Roll back on the version you want and confirm. The earlier version is started next to the current one and takes over once it answers — there is no new build.
A rollback does not undo database changes. If a release changed the database structure, restore the database too — see Databases.
Previews for branches
A push to any other branch gets its own preview — a separate address where you can check the changes before they go live. Open them on the Previews tab.
- Up to 3 previews at a time, included in your price.
- A preview without new pushes for 7 days is removed. It is made again with the next push to that branch.
- Previews get only the variables meant for them — see Environment variables.
- Previews are made for the main service of a project, not for its other services.
A password for previews
On the Previews tab, Password for previews → Ask for a password. Enter a user name and a password (at least 8 characters). From then on only people with the password can open the previews; the application itself stays open to everyone.
The release command (migrations)
The Processes tab → Release command. It runs once on every deploy, before the new version receives visitors — usually database migrations. If it fails, the deploy stops and the current version keeps running, so a broken migration never reaches your visitors.
We suggest a command for the frameworks that have one:
| Framework | Recommended release command |
|---|---|
| Laravel | php artisan migrate --force |
| Django | python manage.py migrate --noinput |
| Prisma (Node.js) | npx prisma migrate deploy |
Use the recommended command keeps it; you can also enter your own or choose None. Changes apply from the next deploy.
Build settings
Settings → Build settings lets you change what we detected:
- Install command — e.g.
npm ci - Build command — e.g.
npm run build - Start command — the command that starts your application. It must listen on the port in
$PORT. - Output folder — for static sites, the folder with the built files.
- Project folder — for a repository with several projects.
Leave a field empty to use what we detected. The next deploy is built with the new settings; Build now starts it right away.
Settings also holds the Branch that is deployed.
Deploy hooks
Settings → Deploy hooks → Create a hook. A deploy hook is a private address: when another service sends a POST request to it, the latest commit of your branch is built and deployed. A typical use is a CMS that rebuilds the site after you publish.
curl -X POST "<the hook address from the panel>"- The address is shown once — copy it when you create the hook. Anyone who has it can start a deploy, so keep it private.
- Up to 10 deploys an hour per hook. A call that arrives while a build is still waiting joins it.
- Revoke stops the address at once; services that call it then need a new one.
Maintenance mode
Settings → Maintenance mode → Show the maintenance page. Visitors see a short page with your message instead of the application; leave the message empty to show «We are making a few improvements. Please check back in a little while.»
The application itself keeps running, so you can check everything before opening it again. A private link for you shows the application as usual on the device that opens it, for 12 hours. New link makes a fresh one; the old link stops working.
Turn the switch off to open the application to visitors again.
Notifications about deploys
We email you (and send a Telegram message, if you have connected it) when a deploy doesn't finish. To send events to your team as well — a new version went live, a deploy did not finish, a service stopped or came back, high memory or processor use, a backup or a database disk — add Slack, Discord or your own webhook in Settings → Notifications to your team. Webhook messages are JSON signed with a secret shown once, in the X-Rivervo-Signature header.