Migrating from Envoyer to DeployHQ

Envoyer is a polished, Laravel-flavoured deployment dashboard from the team that built Laravel itself. It is well-maintained, well-loved in the Laravel community, and genuinely good at what it does. This guide is not about fixing a problem with Envoyer.

It is about three specific situations where DeployHQ tends to be the better fit:

1. You have more than one or two projects. Envoyer charges per project; once you cross three or four projects the maths starts to favour a flat per-account plan.
2. Your stack is not only Laravel (or even only PHP). If your team also ships Node, Ruby, Python, or static sites, having one deploy dashboard per language is unsustainable. DeployHQ deploys any stack to any SSH-reachable host (plus FTP, S3, Heroku, Elastic Beanstalk, Custom Actions for cloud CLIs, and more).
3. You want a build pipeline that runs off the target server. Envoyer's "Install Composer Dependencies" hook runs composer install on the target. That is fine, until it is not — slow servers, deploys that need to ship to many machines, or build steps that do not belong in production. DeployHQ runs composer install, npm ci, asset builds, and anything else once on our build infrastructure and uploads the resulting release to every target.

For a side-by-side feature comparison, see DeployHQ vs Envoyer. If you are weighing PHP-specific options, DeployHQ vs Deployer covers the script-based alternative. If you also use Laravel Forge for server provisioning, see Migrating from Laravel Forge to DeployHQ — Forge stays, only Envoyer goes away.

Coming from a script-based deploy tool instead of a managed dashboard? See Migrating from Deployer to DeployHQ.

Feature parity: Envoyer to DeployHQ

Both tools are managed dashboards with the same atomic-release model — release directories, a current symlink, zero-downtime deploys. The mechanism is nearly identical; the configuration just lives in a different UI.

What DeployHQ adds that Envoyer does not

Migration in three steps

1. Set up the DeployHQ project

Create a new DeployHQ project for each Envoyer project you are migrating. Connect the same Git repository — DeployHQ generates read-only deploy keys automatically, so you do not need to reuse Envoyer's keys.

Add your existing servers to the project. Reuse the same SSH user and deploy path. Most teams keep both Envoyer and DeployHQ deploying to the same servers in parallel during the cut-over so they can compare outputs before disabling Envoyer.

2. Move composer / npm into the build pipeline

This is the biggest shape-change. In Envoyer, "Install Composer Dependencies" runs on the target server during every deploy. In DeployHQ, it runs once on our build infrastructure and the resulting release is uploaded.

A typical Laravel project's build pipeline:

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

These commands run before any file is uploaded to your servers. The compiled vendor/ directory and built assets ship as part of the release. If you have multiple servers, the build runs once and the same artefacts go to all of them — Envoyer would have run composer install separately on each.

If you have project-specific build environment requirements (PHP 8.3 vs 8.2, specific Node version), set them in the build pipeline configuration, or commit a .deploybuild.yaml to your repo.

3. Translate hooks into SSH commands

Envoyer's pre/post-activate custom hooks become DeployHQ SSH commands tied to the appropriate deploy stage:

A typical Laravel project's hooks:

• php artisan migrate --force → SSH command, after upload, before symlink change
• php artisan config:cache && php artisan route:cache && php artisan view:cache → SSH command, after upload (or moved into the build pipeline if your config does not depend on environment values resolved on the target)
• php artisan queue:restart → SSH command, after deploy
• php artisan horizon:terminate → SSH command, after deploy

If your Envoyer hook scripts referenced {{release}} or {{project}}, the DeployHQ equivalents are %release_path% and %project%. See text variables for the full list.

For most Envoyer projects, end-to-end migration is a half-day per project. Concierge migration is available on Pro and above — point us at your Envoyer project and we will rebuild the DeployHQ equivalent with you on a screenshare.

What teams ask before they switch

What about Envoyer's Scheduler feature? DeployHQ does not natively monitor php artisan schedule:run execution. The pragmatic replacement is a normal cron entry on the server (which is what Envoyer's Scheduler is under the hood, plus monitoring) combined with a heartbeat service like Better Stack — see sending deploy events to Better Stack, which can be extended to monitor scheduled-task heartbeats too. If centralised cron monitoring is a hard requirement for your team, this is the one Envoyer feature DeployHQ does not directly replicate.

Can I keep using my existing Envoyer servers? Yes. DeployHQ deploys to any SSH-reachable host. Bring your own VPS, dedicated server, or cloud instance — the same servers Envoyer was deploying to.

What about heartbeats and health checks? Envoyer has built-in heartbeats; DeployHQ defers to dedicated uptime tools like Better Stack via integration. For most teams the integrated approach is more flexible (one heartbeat dashboard for everything, not just deploy-related checks), but it is one extra tool to configure.

Will my deployment notifications survive? Yes. DeployHQ supports Slack, Discord, Microsoft Teams, email, and many other notification channels via integrations. You configure them per project rather than per channel.

Can I migrate just one project to test, and keep the rest on Envoyer? Yes — this is the recommended approach. Migrate one project, run both dashboards in parallel for a deploy or two, verify the output is identical, then disable Envoyer for that project. Repeat per project until you are ready to cancel Envoyer entirely.

Do I lose Envoyer's Laravel-specific niceties? Some of them, like the Scheduler. But Envoyer's Laravel "niceties" are mostly preset hooks for things like php artisan migrate — which you set up once in DeployHQ and never touch again. The trade-off is gaining a tool that also deploys your Node API and your static site without paying for three different services.

What if I want to roll back? One click. DeployHQ keeps your last N releases on the server (you configure N). Rollback flips the symlink back. No different from Envoyer.

Start your migration

Start a free DeployHQ project — connect your repo, point at one server, and deploy in under 15 minutes. No credit card. Run it side-by-side with Envoyer for a deploy or two before cutting over.

If you also need a server, the Managed VPS beta provisions one inside the same dashboard.

Envoyer is a trademark of Laravel LLC. DeployHQ is not affiliated with Laravel or Envoyer. We just understand what the migration looks like when one dashboard outgrows another.