ZDT Deployment for PHP
Zero-Downtime Deployment for PHP
Zero-Downtime Deployment enables PHP applications to be updated without interrupting active user sessions or returning deployment-related errors. The platform prepares the new application version separately and switches incoming traffic only after deployment is successfully completed.
How Zero-Downtime Deployment Works
Application redeployment can temporarily make a website unavailable while files are replaced. Traditional solutions often require extra servers, a load balancer, external deployment tools, and additional configuration. The platform provides an atomic deployment mechanism for PHP applications that avoids these requirements.
The mechanism is based on two core principles:
After the new application version is fully prepared, the symbolic link is switched instantly. New requests are routed to the updated version while existing sessions can finish on the previous one. This makes the update atomic and transparent to application users.
Availability
The availability of Zero-Downtime Deployment depends on the configuration provided by your hosting provider.
ZDT Deployment Workflow
Create a new PHP environment or use an existing one. Apache PHP is used in this example.
Deploy the required application and enable the Enable zero-downtime deployment option in the deployment confirmation window.
The option is available for applications deployed from a local archive, a direct URL, or a version-control repository.
Deployment from an Archive or URL
Existing ROOT application
During the first atomic deployment from an archive or URL to an existing ROOT context, the previous ROOT data is normally replaced by a clean deployment of the application package.
Deployment from Git or SVN
- The Zero-Downtime option is active only for the ROOT context of a PHP application server. Other contexts use classic deployment.
- For VCS projects, the selected deployment mode is remembered and reused for future automatic updates until changed manually.
- Avoid hard-coded absolute paths because each atomic deployment uses a new timestamped directory.
During the first deployment, the platform creates a directory named in the following format:
It also creates a special ROOT symbolic link that points to this directory.
To view the symbolic link and its destination through SSH, run:
During the next deployment, a second timestamped directory is created. The current application remains online while the new files are prepared.
After unpacking or updating is complete, the ROOT symbolic link switches to the new directory. New requests use the updated version, while the previous directory remains available for sessions that began before the switch.
User-generated content
For archive or URL deployments, user-generated content inside the previous application directory must be moved manually to the new directory when required.
For VCS deployments, tracked and untracked application files are copied automatically. Use a properly configured .gitignore file to avoid copying unnecessary content during repeated updates.
Future atomic deployments follow the same process. The platform creates a new timestamped directory and removes the oldest application directory.
By default, the application server keeps two deployed versions: the active version and the preceding one. This limits additional disk-space consumption. An older version can also be removed manually when it is no longer required.
Preserve a specific version
Rename a timestamped application directory before the next deployment to prevent that directory from being removed automatically.
The complete process is automated and does not require an application-server restart. The deployment is performed in a soft mode, so the application continues serving users throughout the update.
ZDT Implementation on PHP Servers
Apache PHP
Apache PHP implements symbolic-link switching through the mod_realdoc module. Its configuration is available in:
RealpathEvery parameter
The RealpathEvery value controls how long the symbolic-link path is cached and how frequently it is refreshed. The platform commonly sets this value to 2 seconds so deployment and switching can finish before requests are redirected.
A custom value can be applied, but the application-server node must be restarted. Avoid excessively high values because they delay symbolic-link switching.
NGINX PHP
NGINX PHP provides atomic deployment through built-in functionality and does not require an additional module. The relevant settings are located near the end of:
Classic and Atomic Deployment Comparison
The original test used a basic WordPress installation and Apache JMeter to send continuous concurrent requests before, during, and after redeployment. The graphs compare successful requests, errors, and response time.
Archive Deployment
With classic archive deployment, the application generally responds quickly before and after the update, but failed requests can occur while the previous package is replaced. In the documented test, errors were visible for approximately two seconds.
With Zero-Downtime Deployment, response time remains stable with only a small temporary increase while the update runs in parallel. The test shows no failed requests during deployment.
VCS Deployment
Classic Git or SVN deployment updates the changed files in the active application directory. When files currently used by the application are replaced, temporary downtime and failed requests can occur. The documented test recorded an interruption lasting nearly four seconds.
Atomic VCS deployment keeps the active version online while the project is copied and updated in a separate directory. Response time may increase slightly, but incoming requests continue to be processed successfully.
Benefits and Conclusion
Expected result
The updated PHP application version is deployed in a separate directory, the ROOT symbolic link switches to it after successful deployment, and users continue accessing the application without interruption.