Docker Jobs Bundle Laravel Package

Technical Evaluation

Architecture fit. Critical mismatch to flag upfront: this is a Symfony bundle, not a Laravel package, despite the brief. Laravel consumes Symfony components (HttpFoundation, Console, Process, Finder) but not bundles — there is no bundle registration, no config/packages/*.yaml merge, and no compiler-pass extension point in the shape this package assumes. It also presumes a Symfony console application context and a host with Docker CLI/daemon access. Net: this is not installable into a Laravel app without a bridge or fork; "composer require and go" is not a realistic path.

Integration feasibility. Feasible, but the cost is in adaptation, not adoption. The genuinely valuable core is likely small — job definition, docker run invocation (probably via symfony/process), exit-code capture, log collection. A short spike should determine whether to bridge the bundle or reimplement ~300–500 LOC natively. Given 19 stars and 0 dependents, the reimplementation path is plausibly lower-risk than inheriting the dependency.

Technical risk.

• Staleness: last release 2022-08-21 (~3 years). PHP 8.2/8.3/8.4 and Symfony 6/7 compatibility unverified; likely absent.
• Bus factor 1. Zero dependents means effectively no production exercise anywhere.
• Security: a batch system that shells into the Docker socket is root-equivalent on the host. Anything job-payload-controlled (image name, command args, mounts, env) becomes a container-escape vector.
• Opportunity score 0.38 reinforces limited ecosystem momentum.
• MIT license is clean; no legal friction.

Key questions.

• Does it drive the Docker CLI via Process, or the Engine API? Can it target a socket proxy or remote daemon?
• How are jobs declared (attributes / YAML / PHP classes), and can they be mapped onto Laravel Job semantics?
• What is the retry / timeout / cleanup contract? Are orphaned containers reaped?
• Private registry support, pull policy, cpu/mem limits, volume mounts?
• Is output streamed or buffered? Is there a structured result object, or just an exit code?
• Any test suite or CI matrix? Is the maintainer responsive, or do we plan to fork on day one?

Integration Approach

Stack fit. Poor-to-moderate out of the box; good only in a narrow band: a Laravel monolith running on Docker hosts that needs isolated batch execution for heterogeneous runtimes (Python, Node, ML binaries) it can't host in-process. Bad fit for Vapor/serverless or shared hosting.

Migration path — three options, ranked:

1. Fork-and-adapt (if the core logic audits well): vendor the bundle, strip Symfony DI/config, expose a Laravel service provider plus facade. We own the code, risk is bounded, and we can pin a known-good commit.
2. Native reimplementation (likely best): model each unit of work as a Laravel Job on a queue; the worker runs docker run or calls the Engine API with explicit limits, streaming logs to the configured driver. This inherits Horizon's retry, backoff, and monitoring — composing with infrastructure we already operate rather than introducing a second job model.
3. Hybrid sidecar: run the bundle inside a small Symfony worker service, talk to Laravel over the queue or HTTP. Isolates the stale dependency at the cost of a new deployable.

Always price the do-nothing baseline first: Kubernetes Jobs, ECS RunTask, or a scheduled docker compose run already cover much of this if the org is container-native.

Compatibility. Verify PHP 8.1+ and Symfony 5.4/6.x support; check for symfony/process version conflicts against Laravel's pinned constraint. Confirm Docker Engine API level (v1.41+) and whether it assumes a specific compose file or base image.

Sequencing.

1. Week 1 — spike: run the bundle in a Symfony skeleton, map its public API surface, measure the LOC of the actual orchestration logic.
2. Week 1–2 — security review: privilege model of the Docker invocation path (rootful socket vs. socket proxy vs. rootless).
3. Week 2–3 — decision gate: bridge vs. reimplement. POC one real job end-to-end: build image → dispatch → stream logs → exit code → cleanup.
4. Week 3–4 — integration: wire to queue/Horizon, add observability, write the runbook.
5. Then pilot on a single non-critical batch workload before any broader rollout.

Operational Impact

Maintenance. Assume we own it. Zero dependents, a single maintainer, and a three-year release gap mean upstream fixes should not be planned for. Budget recurring work for PHP/Symfony major bumps and Docker Engine API drift — roughly 5–10% of one engineer ongoing, not a one-time integration cost.

Support. No vendor, no community, no SLA, minimal issue history to search. Institutional knowledge lives in whoever writes the integration; the runbook is the only durable asset. Contrast with Horizon/Queue, where the team has existing muscle memory and a hiring pipeline.

Scaling. Throughput is bounded by the Docker host: image pull time, layer cache, disk, and concurrent-container limits. Horizontal scale requires multi-host scheduling (Swarm/K8s/Nomad) — a project an order of magnitude larger than this package implies. Above a few dozen concurrent jobs, we are buying an orchestrator, not a bundle. Also budget per-job latency: docker run adds hundreds of milliseconds to seconds versus an in-process job.

Failure modes.

• Orphaned containers after a worker crash — requires a reconciler/reaper.
• Daemon unavailable producing job failures indistinguishable from workload errors unless classified.
• Disk exhaustion from accumulated images and container logs.
• Silent partial failures if exit codes aren't reliably propagated.
• Socket exposure: a compromised job payload equals a compromised host. Mitigate with a restricted socket proxy, rootless Docker, or remote builders.
• Timeouts that don't actually kill the container.
• Secrets passed as docker run env vars are visible via docker inspect to anyone with daemon access.

Ramp-up. Even the bridge path requires the team to learn Symfony bundle conventions — YAML config trees, service tags, compiler passes — which is roughly 1–2 weeks to competence for a Laravel-only group. Add container-lifecycle debugging (log drivers, cgroup limits, network modes). The native reimplementation path, by contrast, ramps on skills the team already has plus modest Docker CLI work, which is the strongest single argument for choosing it over the bundle.