Every deploy is a plan first and a log after. Nothing happens on the server that the log doesn't show.
Two ways to deploy
- Releases (Laravel, Statamic): each deploy uploads a new release folder beside the live one, runs its hooks there, and then switches
currentto it in one step. Shared files (.env,storage, Statamic'scontentwhen it's edited on the server) live outside the releases. Only what changed is sent. - Sync (WordPress, plain PHP): the site's folder is updated in place, with a snapshot of every file the deploy changes or deletes, so a rollback can put them back. Paths people change on the server are protected: never sent, never deleted.
The check
After the switch, XenoDeploy proves the site is served from the new release: a marker file and a small probe, then a request to the site's URL. If the check fails, the new release is live, and XenoDeploy asks: Roll Back or Keep It Live.
Drift
If files on the server changed since the last deploy (a Control Panel edit to a Statamic blueprint, a plugin's file edited in place), the plan lists them and the deploy stops. Download them for diffing, bring the change into git, and deploy again. Ignore Drift deploys anyway; the record says so, and the changed files stay only in the old release.
Rolling back
- Releases: Roll Back…, or Roll Back to This… on any release that was live, points the site back at it and runs your rollback hooks. Migrations aren't undone: the plan warns you when a newer release ran them.
- Sync: Roll Back… restores the newest snapshot: changed and deleted files come back, and files the deploy added are removed.
Rolling back, releases, logs, the shell and Doctor never need a license.
If you close the window
A deploy's work on the server runs on the server. If your Mac sleeps or the app quits mid-deploy, it carries on, and Attach follows it again and runs the check it waits for.