Zero Downtime WordPress Deployments with Trellis

Trellis offers zero downtime WordPress deployments using atomic deployment strategies out of the box. This is a feature that’s standard in modern application development, but rare in the WordPress ecosystem.

You don’t need to use Trellis for your entire development workflow to benefit from these deployment capabilities. Many developers are using Trellis solely for deploying Bedrock-based WordPress sites to various hosting providers including Kinsta, RunCloud, and other managed hosts, while using their preferred local development environment.

What zero downtime deployments actually mean

Zero downtime deployments ensure that your website remains fully functional and accessible to users throughout the entire deployment process. Unlike traditional WordPress deployments where files are overwritten in-place (potentially causing broken functionality during the upload), zero downtime deployments use atomic deployment strategies to prepare the entire new release in isolation before switching over instantly

The traditional WordPress deployment problem

Most WordPress sites are deployed using one of these approaches:

• FTP uploads: You manually upload changed files, overwriting the existing ones. During this process, which can take several minutes, your site serves a mix of old and new files, often resulting in broken functionality.
• File synchronization tools: Tools like rsync copy files from local to production. While faster than FTP, you still have the same fundamental problem: files are being overwritten while the site is live.
• Plugin-based deployment: Many managed WordPress hosts offer plugin-based deployment systems. While convenient, these typically suffer from the same issue: files are updated in-place without any rollback mechanism.

All of these approaches share common problems: your site can break during deployment, there’s no easy way to rollback if something goes wrong, and your users might encounter errors during the deployment window.

How Trellis solves this with atomic deployments

Trellis uses an atomic deployment strategy borrowed from modern application deployment practices. Atomic deployments ensure that the switch from your old version to your new version happens instantaneously—there’s no intermediate state where your site serves a mix of old and new files.

This approach is also immutable. Once a release is deployed, its files are never modified in place. Each deployment creates a completely new, isolated release directory. Here’s how it works:

Directory structure

When you deploy to a server with Trellis, it creates a specific directory structure:

/srv/www/example.com/
├── current/             # Symlink to active release
├── releases/            # All deployed releases
│   ├── 20250930124530/
│   ├── 20250930083045/
│   └── 20250930141622/  # Most recent
├── shared/              # Shared files across releases
│   └── uploads/
└── logs/

The magic happens with the current symlink. Your web server always serves files from the current directory, which is just a symbolic link pointing to one of the release directories.

The deployment process

When you run trellis deploy production, here’s what happens behind the scenes:

• Initialize: Trellis ensures the directory structure exists and creates a new release directory with a timestamp (such as 20250930141622)
• Update: The latest code is cloned from your Git repository into a temporary source directory, which happens completely separate from your live site
• Prepare: Files are copied from the source to the new release directory
• Build: Trellis runs composer install to download dependencies
• Share: Shared files and directories (like uploaded media files) are symlinked from the shared directory into the new release
• Finalize: Trellis updates the current symlink to point to the new release directory

One moment your site is serving files from releases/20250930124530, and the next it’s serving from releases/20250930141622. There’s no period where files are being overwritten or where users might see a broken site.

Database considerations

It’s important to note that while Trellis handles zero downtime deployments for your codebase, database migrations are a separate concern. As the Trellis documentation notes: “Database migrations to a new schema are not included as part of a Trellis deploy.”

If you use Acorn, you can create Laravel migrations for your WordPress sites and make sure that they’re executed as part of the deployment process.

Built-in rollback capabilities

One of the biggest advantages of atomic and immutable deployments is instant rollback capability. Because each release exists as a complete, separate directory that’s never modified after deployment, rolling back is simply a matter of updating the symlink to point to a previous release. If something goes wrong with your new deployment, you can immediately roll back to the previous version:

trellis rollback production

This command updates the current symlink to point back to the previous release. By default, Trellis keeps the five most recent releases on your server.

Deployment hooks for customization

Trellis includes hooks that let you customize each step of the deployment process:

• deploy_build_before and deploy_build_after for custom build steps
• deploy_finalize_before and deploy_finalize_after for pre and post-deployment tasks
• Hooks for each major deployment step: initialize, update, prepare, build, share, and finalize

These hooks enable deployment patterns like:

• Running database backups before deployment
• Clearing cache systems after deployment
• Sending deployment notifications to your team
• Running smoke tests against the new release

Getting started

If you’re not already using Trellis, getting started with zero downtime deployments is straightforward:

1. Set up your project with Bedrock for better WordPress project structure
2. Install Trellis and configure your deployment settings
3. Configure your wordpress_sites.yml with your Git repository information
4. Run trellis deploy production

Your first deployment will take longer as it sets up the directory structure and installs all dependencies. Every subsequent deployment will be faster and, more importantly, zero downtime.

You can use Trellis just for deployment while using your preferred local development environment (Laravel Valet, Lando, DDEV, etc.) and deploying to servers that you didn’t provision with Trellis.