- Is madalynn/plum a Laravel package?
- No. Plum is a framework-agnostic, object-oriented PHP deployment library distributed via Composer, and it ships no service provider, config file, Artisan commands, or Laravel-aware hooks. It can live inside a Laravel repository because Laravel is just a Composer project, but you are treating it as a library you build a deploy script with rather than a batteries-included product. Think Deployer-as-a-library, not Envoyer-as-a-service.
- How do I install Plum in a Laravel project?
- Install it as a dev-only dependency with composer require --dev madalynn/plum, write a plum.php bootstrap file at the repository root, and invoke it from CI or a Composer script. Never add it as a runtime or production dependency. Because there is no meaningful semver guarantee, pin it to a specific commit SHA and commit your composer.lock.
- Does Plum work with Laravel 11 and PHP 8.2?
- Probably not out of the box. Plum's Symfony constraints and PHP floor come from the PHP 5.x and 7.x era, while modern Laravel 10 and 11 pull Symfony 6 or 7 on PHP 8.2+, so composer require is likely to fail or force a platform downgrade. Validate this in a throwaway branch before any planning commitment, and if the resolution fails, close the evaluation and record the constraint conflict as the finding.
- What can you actually do with Plum's recipe DSL?
- Plum exposes a recipe DSL covering servers, roles and stages, tasks, copy and symlink strategies, and before/after callbacks. It is built on top of Symfony Console, Process, Filesystem, and EventDispatcher, so the primitives are familiar to anyone who has written a custom deploy script. Everything deployment-specific, such as your release layout and hooks, is code you write yourself.
- How does Plum handle releases, symlinks, and rollback?
- Plum uses a symlink-based release model, but correctness is entirely your responsibility. Atomicity of the symlink swap, deploy locking, and rollback behaviour are not handled for you and must be designed into your recipe. Test these paths against a staging host before trusting them in production.
- How does Plum handle SSH credentials, secrets, and host keys?
- Handling of SSH credentials and agent forwarding is opaque, and the library relies on host rsync plus the ssh2 extension being available on runners and target hosts. There is no documented secrets management layer, so keep secrets in your CI provider or environment and verify host key checking explicitly. Document your concurrency and deploy-lock strategy separately, because Plum does not provide one.
- Is madalynn/plum actively maintained and safe for production?
- Treat it with caution. It has roughly 86 stars and zero dependents, a single maintainer, and no visible release cadence, so no downstream ecosystem has validated the API surface. Assume you will vendor a fork within 12 months and budget roughly 10 to 20 percent of one engineer's time for fork upkeep on PHP and Symfony bumps plus SSH behaviour changes.
- How does Plum compare to Deployer, Laravel Envoyer, or a GitHub Actions rsync script?
- Plum is a build-your-own-deployer kit rather than a supported, batteries-included tool, and its core job is rsync plus a symlink swap. For a Laravel shop already using Envoy or Deployer, moving to Plum is a lateral step with strictly less community support, and Envoyer is a hosted product rather than a library. Ask what Plum gives you that Deployer or a 30-line GitHub Actions rsync job does not.
- How do I migrate an existing deploy pipeline to Plum?
- Do not rip out a working pipeline. Run an isolated spike in a scratch repository to prove Composer resolution and a working copy-to-symlink deploy against staging, then port one non-critical service's recipe to parity, then run both pipelines in parallel for several releases while comparing timings and failure behaviour. Keep the incumbent pipeline documented as the rollback path until a go/no-go decision is made.
- What should I check in CI before adopting Plum?
- Verify against the exact Laravel minor, PHP minor, and Symfony major you run, and confirm rsync, ssh, and the ssh2 extension exist on both runners and target hosts. Pin Plum to a commit SHA and commit composer.lock, since version ranges mean little here. A realistic sequence is a one to two day spike, three to five days of recipe parity on staging, then two or three shadow production deploys before deciding.