- What is deployer/recipes?
- deployer/recipes is a Composer package that bundles ready-made Deployer recipes for frameworks, CMSs, and services, so you can reuse deployment tasks instead of writing them from scratch. It is deployment tooling loaded by the dep CLI at deploy time, not a runtime library for your Laravel app. The repository is archived and the recipes predate Deployer v7.
- Is deployer/recipes still maintained?
- No. The GitHub repository is archived and the last release was 2019-07-01, so there is no active maintenance, CVE triage, or PHP 8.2/8.3 validation. Treat it as legacy reference material rather than a dependency you expect to receive updates.
- Does deployer/recipes work with Deployer v7 and PHP 8?
- Not reliably. The recipes were written against the Deployer v5/v6 API and PHP 7.x, while Deployer v7 requires PHP 8.x and changed recipe bootstrapping, namespaces, and task names. You should expect registration-time fatals or silently missing tasks if you load them unchanged on modern Deployer.
- How do I install deployer/recipes with Composer?
- Mechanically you can add it with composer require deployer/recipes, since it is Composer-installable and MIT-licensed. However, installing the meta-package pulls in recipes for frameworks you may not run and pins you to an archived artifact. For most Laravel teams it is better to copy a specific recipe file into your project instead of adding the dependency.
- Does deployer/recipes include a Laravel recipe?
- Yes, it includes a Laravel recipe, but most of that logic now overlaps with the maintained laravel recipe shipped in deployer/deployer v7. If you are on modern Deployer, start with the built-in recipe and only extract extra tasks if you have a specific gap.
- What Deployer and PHP versions does deployer/recipes support?
- The recipes target the Deployer v5/v6 era and PHP 7.x. Deployer v7 and PHP 8.x are outside the validated range because the package was archived before those releases. Pinning to Deployer ^6.8 and PHP 7.4 keeps it compatible but confines you to legacy, end-of-life runtimes.
- Is deployer/recipes safe to use in production?
- The risk is high: the repo is archived, the code has no PHP 8.2/8.3 validation, and the package has low adoption and no active security response. Composer audit offers little for unmaintained deployment tooling. If you must use it, isolate it to a legacy pipeline and vendor the specific files you need with attribution.
- What are the alternatives to deployer/recipes?
- Use Deployer core's built-in laravel recipe first, and consider maintained packages such as deployer/deployer and deployer/laravel-zero where they fit. For custom behavior, copy the MIT-licensed recipe file into your project-local deploy.php or a small internal package pinned to your Deployer version. A maintained fork is also an option if you need ongoing updates.
- How do I use a recipe from deployer/recipes without installing the package?
- Because the package is MIT-licensed, you can copy the individual recipe file you need into your deploy.php or an internal acme/deploy-recipes package. Keep the attribution and pin the copied tasks to the Deployer version your runners use. This avoids pulling in unrelated recipes and archived dependency risk.
- Can I use deployer/recipes in GitHub Actions or GitLab CI?
- Yes, Deployer runs fine from CI with a PHP image plus the Deployer PHAR or a Composer-installed binary, and deployer/recipes is loaded the same way. The CI integration is not the problem; the archived package and version skew with Deployer v7 are. Validate tasks against a staging host that mirrors production permissions, shared directories, and PHP-FPM/OPcache settings.