Recipes Laravel Package

Technical Evaluation

Architecture fit

• This is CI/CD tooling, not a runtime library. Recipes are PHP classes that extend Deployer's recipe model and are loaded by the dep CLI at deploy time; nothing ships to production with the application.
• Its architectural relevance to a Laravel/PHP product is therefore narrow: it is a curated set of third-party recipes (framework, CMS, and helper tasks) that predates Deployer's consolidation of common recipes into core.
• The Laravel recipe is the only plausibly relevant component for a Laravel stack; most of its logic now overlaps with the maintained laravel recipe shipped in deployer/deployer v7.
• Fit is "optional convenience layer" — the platform does not depend on it, and modern Deployer does not require it.

Integration feasibility

• Composer-installable and MIT-licensed, so mechanically trivial to add — but the last release was 2019-07-01 and the repository is archived.
• The recipes were authored against the Deployer v5/v6 API and PHP 7.x. Deployer v7 requires PHP 8.x and reorganized recipe bootstrapping, namespaces, and task names. Expect registration-time fatals or silently missing tasks.
• Pinning to Deployer ^6.8 / PHP 7.4 to use it conflicts with Laravel 9+ minimums (PHP 8.0+), so the compatible slice is confined to legacy applications on EOL runtimes.
• Viable alternative: extract individual recipe files (MIT permits) into project-local deploy.php or a thin internal package rather than consuming the meta-package.
• Risk level: high — archived code, no PHP 8.2/8.3 validation, zero dependents, and low adoption signals.

Technical risk

• Supply-chain/reliability: archived repo means no CVE triage and no guarantee the Packagist artifact is immutable to a compromised maintainer account; Composer audit offers little for unmaintained tooling.
• Version-skew risk: recipes and core Deployer evolve together; drifting one without the other produces partial task graphs.
• Scope risk: adopting a broad monorepo of recipes pulls in tasks for frameworks we do not run, increasing surface area and review burden.
• Low dependents/opportunity score (20.71) is consistent with a package that has been effectively superseded.

Key questions

• Which specific tasks do we actually need beyond Deployer core's laravel recipe (e.g., specific queue/Horizon, Slack, Sentry, or FPM reload behavior)?
• What Deployer and PHP versions are on our runners and target hosts today, and what is the upgrade horizon?
• Is a maintained equivalent already available (deployer/deployer core, deployer/laravel-zero, or a maintained fork) that removes the need entirely?
• Are we willing to vendor and own a single recipe file with attribution instead of adding a dependency?
• What is our policy on archived Composer packages in the build chain?

Integration Approach

Stack fit

• Sits in the deployment lane only: invoked from a CI job or an ops workstation, executing SSH tasks against app servers. No coupling to Laravel's service container, HTTP layer, or data model.
• Works with GitHub Actions / GitLab CI using a PHP image plus the Deployer PHAR or a Composer-installed binary; integrates naturally with existing secrets for SSH keys and .env provisioning.
• Best fit is as reference material for task definitions, not as a resolved dependency in composer.json.

Migration path

1. Inventory required deploy behavior against Deployer core's built-in laravel recipe; assume ~80% coverage with no third-party package.
2. For gaps, copy the specific recipe file into deploy.php (or an internal acme/deploy-recipes package) under MIT attribution, and pin it to our Deployer version.
3. Do not adopt the meta-package; if a legacy app must use it, isolate it to a deployer/deployer:^6.8 + PHP 7.4 pipeline with an explicit exit ticket.
4. Validate against a staging host that mirrors production permissions, shared-directory layout, and PHP-FPM/OPcache configuration.

Compatibility

• Verify every use statement and task name against the installed Deployer version; v6→v7 changed recipe bootstrapping and several task names (opcache:reset, fpm:reload, queue:restart, Horizon termination hooks) and configuration keys.
• Check writable_dirs, shared_dirs, shared_files, and .env symlink assumptions — these are the most common sources of silent breakage on newer base images.
• Confirm Composer 2 behavior for composer install --no-dev --optimize-autoloader inside the release path, since 2019-era recipes often predate it.

Sequencing

1. Spike (1–2 days): stand up Deployer core + Laravel recipe against staging, document gaps.
2. Port only the missing tasks, with attribution and a minimal test (dry-run + one real deploy).
3. Wire into CI with a rollback rehearsal (dep rollback) on a non-production host.
4. Roll out to production behind the existing change process, then delete any unused recipe code.

Operational Impact

Maintenance

• Effectively zero upstream maintenance; ownership transfers entirely to us at adoption. Archived status means no dependency bot updates and no upstream fixes.
• Budget a recurring review of the vendored recipe files at each Deployer major upgrade; the alternative (pinning old Deployer) compounds runtime EOL debt.

Support

• No maintainer, no issue triage, no release cadence. Deployer's own community channels support core, not 2019 recipe versions.
• Requires an internal owner with Deployer familiarity; onboarding cost is concentrated in one or two engineers, creating a bus-factor risk on the deploy path.

Scaling

• Recipes are static configuration; they do not constrain horizontal scaling directly. Deploy parallelism across hosts is governed by Deployer's inventory and parallel-execution features, which the older recipe style may not fully leverage.
• Multi-host inventories and blue/green or rolling strategies are better served by current Deployer core features than by these recipes.

Failure modes

• Registration-time fatals from API drift — deploy fails immediately and loudly (preferable).
• Silent no-ops: opcache:reset or fpm:reload tasks that no longer match host configuration, leaving stale code serving traffic after a "successful" deploy.
• Partial releases from failed deploy:shared/deploy:writable steps, requiring manual cleanup of the releases directory.
• .env and storage symlink drift producing 500s that only appear post-symlink switch.
• Rollback gaps: deploy:rollback reverts code but not migrations, so recipes that auto-run migrate create an unrecoverable state without a manual plan.
• Credential/secret exposure if recipes embed host paths or environment assumptions that bypass our secrets handling.

Ramp-up

• Low for engineers already fluent with Deployer's task/host/release model; moderate for others, who must learn the recipe abstraction, host inventory, and release-symlink lifecycle.
• Plan roughly one spike day plus CI wiring and a rollback drill; treat the package itself as a code sample to be read, not a component to be operated.

Overall recommendation: Do not adopt deployer/recipes as a dependency. Harvest the specific recipe logic we need under MIT into an internally owned configuration, and standardize on the maintained Laravel recipe in deployer/deployer core. The 3.19 score, archived status, 2019 last release, and zero dependents all point the same direction: reference value only.