Deploy Your PHP Site with DeployHQ: Composer, Laravel, and WordPress

By Adam W · Updated on 25th March 2026

PHP powers a significant portion of the web — from WordPress and Laravel applications to custom-built sites and APIs. While you can deploy PHP by uploading files manually via FTP or using command-line tools like Deployer or Capistrano, a dedicated deployment platform simplifies the process considerably, especially when your workflow involves Composer dependencies, build steps, or multiple environments.

DeployHQ connects your Git repository to your server and uploads only the files that changed in each commit. Combined with build pipelines for Composer and SSH commands for database migrations, it handles the complete PHP deployment workflow. If you're evaluating tools, our DeployHQ vs Deployer comparison covers the key differences.

Basic PHP deployment workflow

The simplest PHP deployment with DeployHQ works like this:

Connect your Git repository (GitHub, GitLab, Bitbucket, or any Git host)
Add your server details (hostname, credentials, deployment path)
Push a commit — DeployHQ uploads only the changed files

For a straightforward PHP site without dependencies or a build step, this is all you need. DeployHQ tracks which commits have been deployed and only transfers the delta.

To get started, sign up for DeployHQ (free plan available) and create a new project pointing to your PHP repository.

Installing Composer dependencies

Most modern PHP projects use Composer for dependency management. Since vendor/ shouldn't be committed to your repository (it adds thousands of files and creates merge conflicts), you need to run composer install as part of the deployment.

DeployHQ's build pipeline handles this by running commands in an isolated environment before uploading files:

composer install --no-dev --optimize-autoloader --no-interaction

The --no-dev flag skips development dependencies (PHPUnit, debugging tools, etc.), --optimize-autoloader generates an optimised class map for production performance, and --no-interaction prevents prompts from blocking the build.

Caching Composer dependencies

To speed up builds, add the vendor directory to your cached build files under Build Pipeline → Build Configuration:

vendor
vendor/**

This keeps a copy of your dependencies between deployments. Composer only downloads new or updated packages.

Laravel deployment workflow

Laravel projects benefit from a more complete deployment configuration:

Build commands

composer install --no-dev --optimize-autoloader --no-interaction
npm ci
npm run build

SSH commands (run after file transfer)

cd /var/www/your-app/current && php artisan migrate --force
cd /var/www/your-app/current && php artisan config:cache
cd /var/www/your-app/current && php artisan route:cache
cd /var/www/your-app/current && php artisan view:cache
cd /var/www/your-app/current && php artisan queue:restart

These commands run database migrations, cache configuration for performance, and restart queue workers so they pick up the new code.

For a detailed walkthrough, see our Laravel deployment guide.

Using atomic deployments with Laravel

Laravel works well with DeployHQ's zero downtime deployments. Move these directories into shared/:

storage/ — logs, cache, sessions, uploaded files
.env — environment configuration

DeployHQ symlinks them into each new release automatically.

WordPress deployment workflow

WordPress deployments work best when you version-control your theme and plugin code while excluding WordPress core and user uploads.

Repository structure

Keep your repository focused on custom code:

├── wp-content/
│   ├── themes/your-theme/
│   ├── plugins/your-custom-plugin/
│   └── mu-plugins/
├── composer.json          # If using Composer for plugin management
└── .gitignore

Build commands for WordPress themes

If your theme uses build tools:

cd wp-content/themes/your-theme && npm ci && npm run build

Shared files

When using atomic deployments with WordPress, move wp-config.php and wp-content/uploads/ to the shared directory.

For a complete guide, see our article on automating WordPress deployments with Git.

Running SSH commands on your server

Beyond migrations, PHP applications often need commands run on the server during deployment:

Restart PHP-FPM: sudo systemctl reload php8.3-fpm (if your deployment user has sudo access)
Clear opcache: Many frameworks provide a command or endpoint to reset the PHP opcache
Start/stop workers: Queue workers, cron schedulers, and other persistent processes
Warm caches: Pre-generate cached views, routes, or configuration

Configure these under SSH Commands in your DeployHQ project. Commands can run before or after files are transferred, depending on what's needed.

Excluding unnecessary files

Keep your deployed codebase clean by excluding files that shouldn't be on your server:

node_modules/ — build dependencies, not needed in production
.git/ — version control metadata
tests/ — test suites
.env.example — template files
README.md, CONTRIBUTING.md — documentation

Configure exclusions under Settings → Excluded Files in your DeployHQ project.

Managing environment-specific configuration

Use DeployHQ's config files feature to manage environment-specific settings like database credentials, API keys, and service URLs. These files are placed on the server during deployment but never stored in your Git repository.

For an alternative approach using encrypted environment variables, see our guide on deploying PHP with Dotenvx.