Deployer Laravel Package

Technical Evaluation

What the artifact actually is. Unchanged in kind: rebelinblue/deployer remains a self-hosted Laravel web application — a deployment management UI (projects → environments → servers → deployments) that pushes code over SSH and records history. The 0-dependents figure still holds: nothing composer requires it; you run it. The TPM decision remains "operate a service" or "harvest a reference architecture," not "adopt a library."

What release 0.0.47 changes about that judgement. Two things, one materially positive, one materially cautionary.

Positive: the prior assessment's central risk — "archived upstream, no maintainer, no CVE response" — is now contradicted by evidence. A release landed, it credits an external contributor (@emielmolenaar), and the fixes are the kind that only come from people actually running the thing in production: passphrase-protected SSL keys, ~ path resolution, full-path symlink targets for shared folders, and error output logging for failed processes. That is a live deployment footprint, not a museum piece. The key-custody story also improves slightly: passphrase-protected private keys are now usable, which allows a stronger key-hygiene posture than plaintext-on-disk keys.

Cautionary: the release is versioned 0.0.47 and ships, under an "Important" banner, a destructive-on-first-deploy filesystem migration. On the first deploy of an existing project the shared folder structure is recreated, existing shared folders are backed up, and files are attempted to be migrated — with the release notes themselves telling you to take your own backup and manually verify placement afterwards. That is a schema migration for a filesystem that holds storage/, uploads, and .env files. Pre-1.0 versioning plus a patch-level bump carrying data-migration semantics means: no API stability guarantee, and release notes are the only changelog contract you get.

Architecture fit. Unchanged. Good fit for many small-to-medium PHP/Laravel apps on VM/bare-metal targets wanting push-button, auditable deploys with per-environment config and rollback. Poor fit where the platform strategy is pipeline-as-code (GitHub Actions, GitLab CI) or immutable containers — this remains SSH-and-symlink oriented and would become a parallel, unaudited deployment path.

Integration feasibility. Unchanged, marginally improved. Outward integration (git webhooks, Slack, arbitrary shell steps) is fine. Inward integration is still absent: no stable public API contract, no embeddable component, an auth layer that predates modern SSO/MFA expectations. The 0.0.47 enhancements improve operability (path handling, error visibility), not integrability. Practical posture remains "run it as an isolated internal service behind an authenticating reverse proxy."

Technical risk — revised.

MIT license continues to remove legal friction for forking.

Key questions to resolve before any commitment.

• Is 0.0.47 the start of a maintenance revival or a one-off contributor patch? Ask for a stated support/cadence commitment, and check commit activity between the 2018 tag and this release.
• Does the shared-folder migration have a documented rollback, and who verifies file placement after the first deploy of each existing project?
• What is the unmet need — deploy visibility/audit for non-engineers, or delivery automation? Does existing CI plus a thin internal dashboard cover it?
• Who owns a fork, and is there appetite for a Laravel 5.x → 10/11 upgrade (auth scaffolding, queue API, Blade/Vue frontend)?
• Do we have a compliance requirement (SOC 2, key custody) that this credential store cannot satisfy even with passphrase-protected keys?
• What is the exit cost if we abandon it in 12 months?

Integration Approach

Stack fit. Treat it as an appliance. Pinned container set: PHP 7.1/7.2, MySQL 5.7, Redis for queues, Node 8 for the one-time asset build, nginx + supervisor + scheduler cron. Pin the Composer lockfile, vendor built assets, and now pin the application release explicitly (0.0.47) rather than tracking master — the version number will not warn you about the next migration. Front with an SSO-terminating proxy and restrict egress to specific target hosts.

Migration path — three options, ranked (unchanged, with revised weighting):

1. Reference-only (still the recommended default). Mine the domain model — deployment state machine, release-directory/symlink strategy, per-environment configuration — and reimplement the thin slice we need on a supported Laravel version. This release arguably strengthens this option: the symlink/full-path and shared-folder work is a free lesson in the edge cases of the release-directory pattern, which is precisely the part worth copying.
2. Fork-and-modernize (now more viable than before). A responsive upstream and a contributor base lower the "you will maintain a dead project alone" cost. Fork, freeze features, run an incremental framework upgrade, and maintain a patch cadence. Budget an ongoing 20–30% of one engineer plus an initial multi-week upgrade push. Condition: get a written support expectation from upstream first.
3. Adopt frozen (frozen at a recent tag rather than a 2018 one). Slightly more defensible than before, but still lab/demo/internal-only unless the security review clears credential storage and network isolation.

Compatibility. Two additions to the existing checklist. First, validate the shared-folder migration on a restored copy of a real project before touching anything live, and diff the resulting directory tree. Second, confirm the host's OpenSSH accepts the key types and host-key algorithms the bundled SSH library negotiates — the ~ and full-path fixes suggest path assumptions have been drifting against modern environments, so assume other assumptions have too.

Sequencing.

1. Discovery — map the actual need against existing CI; kill early if CI + dashboard suffices.
2. Isolated PoC — containerized stack at 0.0.47, one non-critical internal app, synthetic SSH keys, no production reachability.
3. Upgrade rehearsal (new) — run the first-deploy shared-folder migration against a restored snapshot; verify file placement manually; document rollback.
4. Security review — credential storage, passphrase key handling, auth, egress, audit logging; gate for go/no-go.
5. Fork + pin (if proceeding) — named owner, patch cadence, upstream support expectation, framework-upgrade backlog item.
6. Production pilot — one real but low-blast-radius project, rollback rehearsed.
7. Decide build-vs-buy-vs-abandon at the 90-day mark with concrete usage data.

Operational Impact

Maintenance. Still the heaviest line item, but the shape changed. A live upstream means dependency vulnerabilities may get fixed rather than becoming purely our tickets — a real reduction in standing burden, contingent on the cadence being real. Against that, pre-1.0 releases can carry filesystem migrations under a patch version, so every upgrade now needs a changelog read and a backup-verify step, not a blind git pull. The framework-upgrade project (auth, queue, frontend) is unchanged and still effectively a rewrite. Add the standard Laravel operational surface: queue workers, scheduler, storage permissions, log rotation, DB backups.

Support. Was "zero vendor support, zero active community." Now: a small contributor base, at least one recent external patch, still no vendor and no published security policy. Internal ownership remains mandatory — named engineer, runbook, on-call slot — because the tool holds production SSH keys. Single-owner risk persists.

Scaling. Unchanged. Web tier scales horizontally; queue workers are the throughput lever and bound deployment concurrency alongside per-project locking. MySQL is the eventual bottleneck (deployment logs and step output grow fast — plan retention and archival; 0.0.47's verbose failed-process logging slightly increases that growth). SSH fan-out is fine at tens of hosts, not thousands. Comfortable for a mid-size org, poor for a large one.

Failure modes to instrument for.

• Shared-folder migration data loss (new, highest priority) — first deploy of an existing project recreates shared folders and best-effort migrates contents; .env, uploads, and storage can land wrong. Mandatory pre-deploy backup plus post-deploy verification checklist.
• Stuck deployments — queue worker death leaves jobs pending with no timeout; alert on age, not just failure.
• Partial deploys — a failing step mid-sequence leaves a release directory and live symlink in an indeterminate state. Now better observed (failed-process output is logged) but not better prevented; rollback must be rehearsed.
• Credential incidents — a leaked APP_KEY plus DB dump yields every target's SSH key. Passphrase-protected keys now reduce the value of a stolen key file, which makes adopting them a prerequisite rather than an option. Rotation runbook and per-environment key scoping still required.
• Webhook spoofing — an unauthenticated deploy trigger is remote code execution by another name.
• Long migrations — DB migrations run as deploy steps can hang the queue and hold locks; keep them off the deploy path.
• Silent drift — old SSH/webhook handling failing quietly against modernized infrastructure; the tilde/full-path fixes are evidence this class of bug exists and is only being found reactively.

Ramp-up. One to two engineers, roughly two to four weeks to genuine productivity with existing Laravel familiarity. Add a few days specifically for the release-directory/shared-folder model and the 0.0.47 migration procedure — it is now a documented operational step, not just an architectural concept. Required knowledge: Laravel queue/scheduler operation, SSH key lifecycle management including passphrase handling, and the symlink-release deploy model.

Bottom line for the TPM: the risk profile improved but the adoption decision did not flip. Upstream is alive and the key-handling story is better; the framework floor is still EOL, the versioning still gives no safety signal, and the latest release ships a filesystem migration under a patch number. Default remains option 1 (reference-only) — now with a better reference. Permit option 2 with a named owner, a written support expectation from upstream, a security sign-off on credential handling, and an explicit upgrade budget. If adopting, pin 0.0.47 and treat the shared-folder migration as a change-managed event with its own backup and verification steps.