Deploying Statamic to Webslice
A git push builds the site, swaps it live, then warms the static cache. Here is what each step does, and where to look when one of them fails.
A deploy runs in a fixed order, and knowing it makes the logs in the Webslice Console readable.
The build
.webslice/build.sh runs first, in a copy of your repository that is about to become the site. It writes the production environment file, installs Composer and npm dependencies, makes sure there is an application key, and builds the front end assets with Vite. Nothing is serving traffic yet, so a failure here stops the deploy without touching the live site.
Going live
Once the build succeeds the new release starts serving. On the versioned strategy that is a symlink being repointed, so the whole site switches over at once with no half-updated state. On the live strategy only the changed files are synced.
The release
.webslice/release.sh runs last, against the site that is now live. It checks APP_URL is really your site, caches the framework config and routes, clears the old static cache, then warms the new one by requesting every URL at that address. That last step is why the first visitor to a page gets a file off disk rather than paying for a full render.
Why warming matters here
Serverless instances are cold by default. Without a warm static cache, the first request to each page boots PHP, builds Statamic's content index, and renders. With one, Apache reads a file and returns it. The rewrite rules in public/.htaccess are what let it skip PHP entirely, and they are easy to lose in a redesign.