We’re consistently working to make it quicker and easier for you to build and deploy websites on Webslice. One big recent change we’ve made is the addition of Live Git deployments on Webslice Serverless.
You now have the choice between two Git deploy strategies on Webslice Serverless: Versioned or Live. They’re both equally viable, with their own use cases. Versioned is most suitable for websites where zero-downtime is important, and Live for when deploying at speed is your main priority.
A faster deploy process
When you choose the Live deploy strategy, instead of completely replacing your site each time you deploy, your project is built in a temporary staging area. Deployed files are compared against the previous build, and only files that actually changed are copied over. Everything else stays exactly where it is.
It's a faster deploy method, that’s less destructive and smarter about what’s invalidated in the CDN.
How Live deploys work: Content stays where you put it
Live deploys don't just look at what changed in Git. After running your build, Webslice Serverless generates a manifest of every file in the build output—a hash of each file's contents. It then compares that manifest against the one from your previous build. Only files whose contents actually differ get copied to your live site.
This means the comparison happens at the build output level, not the Git level. If your build script produces the same output file from different source commits, that file won't be touched. If it produces a different output from the same source file, it will be updated. What matters is what changed in the final result, not what changed in the repository.
Anything on your live site that isn't in the build output is left untouched. That could include user uploads, plugin directories, media folders, or CMS content. If your build didn't produce it, the deploy won't touch it. For anyone running a CMS, managing content through SFTP, or uploading files via the admin console, this will likely be the biggest change between Live and Versioned deploy strategies.
Live deploys in practice
Here's a practical example. Say your WordPress site has this structure on the live server:
wp-config.php ← tracked in your repo
theme/style.css ← tracked in your repo
wp-content/uploads/ ← user uploads, not in the repo
wp-content/plugins/ ← installed via admin panel, not in the repo
Each time you push a commit that updates wp-config.php. Webslice runs the build, hashes the output, and compares it to the previous manifest. It sees that wp-config.php has a different hash, so it copies the new version across. theme/style.css has the same hash as last time, so it's skipped. The uploads/ and plugins/ directories don't appear in the build manifest at all, so they're completely untouched.
How things worked before
Before we rolled out Live deploys, every Git deploy on Webslice used a Versioned strategy. Each deploy cloned the entire repository, ran a full build, wrote everything to a new versioned folder, and swapped a symlink.
With Versioned deploys, the old version of the site stays live until the new one is ready. It’s a safe approach with zero downtime, and there are plenty of reasons your website could demand this strategy (we list them further down the article).
On the other hand, it's not as quick as Live deploys, and it treats every deploy the same—whether you’ve changed one file or a thousand. Because Versioned deploys replace the entire site, any files your users have uploaded or edited directly get overwritten. That includes all CMS content, images and config.
Both strategies are viable. Choosing between them will depend on your needs and requirements.
Smarter CDN cache invalidation
Versioned deploys purge your entire CDN cache on every deploy, even when a single file has changed. That means every visitor hits your origin server on the next request while the cache warms back up.
On the other hand, Live deploys only invalidate the specific files that were modified. The rest of your cached content keeps serving from the edge, so your visitors don't notice a thing.
Real numbers from a real site
We tested both strategies on webslice.com itself. Our website has over 15,000 files, a Node.js build pipeline, and vendor dependencies. For a single file change we measured the deploy times show below for each deployment strategy:
| Versioned | Live | |
| Deploy time | 3 min 8 sec | 1 min 58 sec |
That's a 37% reduction in total deploy time, and the advantage grows with the size of the change. Versioned deploys process every file regardless; live deploys only move the differences.
Build caching helps here too. Webslice Serverless now stores your node_modules, vendor, and other build dependencies between deploys, so subsequent builds skip the expensive dependency installation step.
When to use each strategy
Live deploys are the right choice for most sites:
Projects where users upload or edit files directly on the server
Any workflow where deploy speed matters
Sites where you want CDN cache to persist between deploys
Versioned deploys remain available for sites that need them:
Zero-downtime atomic swaps where the old site serves until the new one is fully ready
Deterministic CI/CD pipelines that require complete, reproducible deploys
Sites where the repository is the sole source of truth with no user modifications
How to switch
In your project settings, you'll find a new Deploy Strategy option under the Git deploy configuration. Select Live to start using incremental deploys. Existing sites default to Versioned, so nothing changes unless you opt in.
What about rollbacks?
Before syncing any changes, Live deploys back up every file that's about to be modified or deleted. If something goes wrong mid-deploy, those changes are automatically reverted. For manual rollbacks, you can redeploy a previous commit.
Questions or feedback?
We'd love to hear how live deploys are working for your sites. If you have questions or run into anything unexpected, get in touch with our support team.