- How do I install log1x/envoyer-deploy-commands in a Laravel app?
- Install it with Composer using composer require log1x/envoyer-deploy-commands. The package supports Laravel package auto-discovery, so the Artisan commands should register without manually editing config/app.php. After installing, run php artisan list to confirm the deployment commands appear. If you want to customize environment mappings, publish the config file and review it before use.
- Which Laravel versions does version 1.1.4 support?
- Version 1.1.4 is a maintenance release whose only change is a Laravel 12 dependency bump, so it is the release to use on Laravel 12. Because a dependency bump can shift the supported framework range, check the composer.json constraints shipped in that tag before assuming it still installs on Laravel 10 or 11. If you are pinned to an older Laravel major, verify with composer why-not log1x/envoyer-deploy-commands or stay on the previous tag. Confirm your PHP version also satisfies the constraint.
- Does this package call the Envoyer API with an auth token, or does it just hit webhook URLs?
- The package is a thin wrapper that makes outbound HTTP requests to Envoyer deployment hook URLs rather than authenticating against a full API. That means the URL itself is effectively the credential, so treat each hook URL as a secret. It sits at the outermost edge of the application and does not touch your models, database, queues, or request lifecycle. Because it depends entirely on Envoyer's hook endpoints, it is only useful if Envoyer is your actual deploy target.
- What Artisan commands does it add, and how do I run a deployment?
- The package registers Artisan commands that trigger an Envoyer deployment hook, so you invoke it from the terminal instead of opening the Envoyer dashboard. The exact command surface, whether it is one command with an environment argument or per-environment commands, depends on the installed version, so run php artisan list after installing to see what is registered. In practice you call the command with the environment you want to deploy and let it fire the corresponding hook URL.
- How do I configure the environment-to-hook-URL mapping?
- After installing, publish the package config with php artisan vendor:publish and map each environment name to its Envoyer deployment hook URL. Keep the actual URLs in environment variables or your secret store rather than committing them into config files. Review the published file so you know exactly which environment resolves to which hook before running anything. Once the mapping is in place, the command resolves the URL and issues the outbound HTTP request.
- Can I test deployment commands without actually deploying to production?
- Yes, but the safety comes from how you configure it, not from a dry-run flag. Point the config at a non-production Envoyer environment and invoke the command manually there first so you can confirm the hook fires and the response looks right. In an automated test suite you can typically intercept the outbound call with Laravel's Http::fake, since the package's real contract is an HTTP request to a hook URL. Never wire the command into CI with production hook URLs before you have exercised it against a staging environment.
- Can I use it in CI pipelines such as GitHub Actions?
- Yes, this is one of the main use cases: run the Artisan command as a step in a CI job and keep the hook URL in the pipeline's secret store. Before relying on it for pipeline gating, confirm that the command returns a meaningful non-zero exit code and surfaces Envoyer's response, since a fire-and-forget command can let a failed deployment pass silently. Also confirm whether the package accounts for any rate limits or concurrency guards on Envoyer's side. Test the failure path deliberately before making the step required.
- How do I keep Envoyer hook URLs out of version control and logs?
- Store hook URLs in environment variables or your platform's secret manager and reference them from config rather than hardcoding them. Never commit a published config file that contains real hook URLs, and audit your CI logs and Laravel logs to make sure the URLs are not being echoed in exception traces. Rotating a leaked hook URL in Envoyer is the recovery step, so limit who can read the secret in the first place.
- Is it a good fit if I deploy with Laravel Forge, Vapor, or Kubernetes?
- No. The package is only relevant when Envoyer is your deploy target, because its whole purpose is triggering Envoyer deployment hooks from Artisan. On Forge, Vapor, Kubernetes, or other pipelines it adds a dependency with no corresponding capability, and you should use the deployment mechanism native to that platform instead. Even on Envoyer, a one-line curl against the hook URL is a viable fallback if you want zero dependencies.
- What is the maintenance and bus-factor risk of this package?
- The code surface is small and the release history is mostly maintenance, with v1.1.4 being a Laravel 12 dependency bump rather than a feature change, which keeps technical risk low. The dominant risk is that it is maintained by a single author, so long-term support across future Laravel majors is not guaranteed by a team-backed roadmap. Pin the version in composer.json, keep an eye on releases around each new Laravel major, and remember that removal is a simple composer remove with no residual schema or state.