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](https://www.deployhq.com) 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](https://www.deployhq.com/blog/deployhq-vs-deployer-a-comparative-analysis-of-automated-deployment-tools) covers the key differences.

## Basic PHP deployment workflow

The simplest PHP deployment with [DeployHQ](https://www.deployhq.com) works like this:

1. Connect your Git repository (GitHub, [GitLab](https://www.deployhq.com/blog/gitlab-vs-github-2025-in-depth-comparison-platform-choice-guide), Bitbucket, or any Git host)
2. Add your server details (hostname, credentials, deployment path)
3. Push a commit — [DeployHQ](https://www.deployhq.com) uploads only the changed files

For a straightforward PHP site without dependencies or a build step, this is all you need. [DeployHQ](https://www.deployhq.com) tracks which commits have been deployed and only transfers the delta.

To get started, [sign up for DeployHQ](https://www.deployhq.com/signup) (free plan available) and create a new project pointing to your PHP repository.

## Installing Composer dependencies

Most modern PHP projects use [Composer](https://getcomposer.org/) 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](https://www.deployhq.com/blog/the-deployhq-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](https://www.deployhq.com/blog/how-do-you-handle-database-changes-during-a-deployment), cache configuration for performance, and restart queue workers so they pick up the new code.

For a detailed walkthrough, see our [Laravel deployment guide](https://www.deployhq.com/blog/how-to-deploy-laravel-zero-downtime-build-pipelines-and-best-practices).

### Using atomic deployments with Laravel

Laravel works well with DeployHQ's [zero downtime deployments](https://www.deployhq.com/blog/setting-up-zero-downtime-deployments). Move these directories into `shared/`:

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

[DeployHQ](https://www.deployhq.com) 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](https://www.deployhq.com/blog/automate-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](https://www.deployhq.com) 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](https://www.deployhq.com) project.

## Managing environment-specific configuration

Use DeployHQ's [config files](https://www.deployhq.com/support/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](https://www.deployhq.com/blog/how-to-deploy-php-applications-with-encrypted-environment-variables-using-dotenvx-and-deployhq).

## Further reading

- [5 powerful ways to deploy PHP applications](https://www.deployhq.com/blog/5-powerful-ways-to-deploy-php-applications-with-deployhq) — advanced patterns and strategies
- [What's new in PHP 2026](https://www.deployhq.com/blog/what-s-new-in-php-2026-modern-features-for-production) — modern language features for production
- [Excluded files](https://www.deployhq.com/support/excluded-files) — keep unwanted files off your server
- [Integrations](https://www.deployhq.com/support/integrations) — connect with Slack, email, and other services for deployment notifications

* * *

Ready to streamline your PHP deployments? [Sign up for DeployHQ](https://www.deployhq.com/signup) and deploy your first project in minutes.

If you have any questions about deploying PHP sites, contact us at [support@deployhq.com](mailto:support@deployhq.com) or reach out on [X (Twitter)](https://x.com/deployhq).