Deployments

Starting a deploy

• The app. Deploy in the site’s toolbar, Deploy and the domain in ⌘K, or Redeploy beside a failed deploy on Today. The output streams into the console.
• Push to deploy. For repositories connected through the Provisore GitHub App. A site connected with a deploy key alone never receives a push event, so use a deploy hook for those.
• Deploy hook. A per-site URL you can call from CI or any Git host. See Webhooks.
• API. POST /v1/sites/{id}/deployments with a scoped access token.

Repeated triggers within the same minute count as one deploy, so a webhook that retries does not queue a second identical run.

A site can hold every deploy until the commit’s GitHub checks pass, and a staging site can promote its live commit to production. See Checks & promotions.

A pull request can also get a deployment of its own instead of deploying over the site. See Preview environments.

What a deploy does

1. scaffold creates the site directories if they are missing.
2. fetch-source clones the branch into a new release directory and records the commit.
3. write-environment installs the current environment version at shared/.env with mode 0600. It is uploaded over SFTP and does not appear in the log.
4. runtime installs the language toolchain if the server does not have it. It runs after the fetch, so a bad repository URL or a missing branch fails before the toolchain downloads.
5. your deploy script runs composer install, npm ci && npm run build, php artisan migrate, or whatever else your application needs. It is written for you when the site is created and is yours to edit. See Deploy scripts. SwiftPM is the exception: swift build -c release is a built-in step.
6. configure writes the PHP-FPM pool or systemd unit, then renders and validates the Nginx vhost.
7. activate swaps the symlink, reloads the service, and runs the health check.
8. prune-releases keeps the five newest successful releases. The release current points at is never removed.

Everything before activation runs against the new release while the old one keeps serving traffic. Activation reloads PHP-FPM gracefully: requests already running get up to 5 seconds to finish before the old workers stop, and new ones wait for the new workers. A failure at any step stops the deploy and leaves the running release in place.

The health check

After the symlink swap, Provisore checks that the site responds and rolls the release back if it does not.

• Root check. The default when the site has no health path. Requests / and fails on a 5xx, a refused connection, or a timeout. 2xx, 3xx, and 4xx all pass.
• Path check. Used when the site names a health endpoint. Stricter, and follows redirects, so a site that forces HTTPS is checked at its real destination.
• Off. A per-site setting for applications whose root returns 5xx on purpose. The deploy log records that the check was skipped.

A site in maintenance mode is not health-checked, because it returns 503 to every request while it is down.

Rollback

Previous releases stay on disk. Rolling back re-activates one of them with the same health-checked symlink swap, with no fetch, no build, and no reconfiguration. It usually takes under two seconds. Roll back in the site’s toolbar returns to the release before the live one. Any other kept release has its own Roll back to this release button in the Deployments view. Both ask you to type rollback. Deployments newer than the one you roll back to are marked rolled_back.

Database migrations are not reversed. A rollback restores code, not schema. If a release migrated destructively, roll forward with a fix instead.

Following a deploy

Every deploy is a job. Jobs move through waiting → queued → running → succeeded or failed, stream their output live, and can be cancelled while they run. The console’s Jobs tab (⌃`) and the Activity page keep the team’s recent history, so a failed deploy is still there after you have moved on.