Docker Jobs Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. adopt for batch execution. This package is a reference implementation of "one container per job" batch processing: a job is dispatched, a Docker container is spun up for it, work runs in isolation, the container is torn down. That directly informs whether we build our own containerized job runner, adopt a managed orchestrator (AWS Batch, ECS RunTask, Cloud Run Jobs, Kubernetes Jobs), or keep simple always-on queue workers.
• Feature feasibility for isolation-heavy workloads. It gives us a concrete cost/latency model for use cases that actually need per-job isolation: multi-tenant or customer-supplied code execution, document/PDF generation with heavy native deps, media transcoding, ETL/backfills, scraping, ML inference, and any job whose dependency tree conflicts with the main app (different PHP version, different extension set, different library major).
• Heterogeneous-runtime roadmap decisions. If the roadmap includes running jobs that can't live in the monolith's runtime (other languages, pinned legacy runtimes, GPU/binary tooling), a container-per-job model is the enabling primitive. This package shows the Symfony-native ergonomics of that (DI-configured jobs, container lifecycle handled for you), which is a useful input when scoping the internal platform work.
• Cost and latency trade-off modeling. Container cold-start (seconds) vs. throughput. This is a decision input for whether bursty/rare-but-heavy jobs justify container spin-up, and whether sustained high-volume jobs should stay on persistent workers instead.
• Risk-scored vendor/OSS shortlist. 19 stars, 0 dependents, last release Aug 2022, opportunity score 0.38 — the package is a design reference and forking candidate, not a supported dependency. That is itself a decision: budget ownership for maintenance rather than assuming a community will carry it.
• Platform standardization. If we already run Docker on our hosts and have no Kubernetes, this pattern is the cheapest path to job isolation; if we already have K8s, this is largely redundant with K8s Jobs/Argo and the decision flips to "don't build."

Important scoping note for a Laravel shop: this is a Symfony bundle, not a Laravel package. There is no drop-in path — bundles rely on Symfony's kernel/DI container and bundle autoconfiguration. In Laravel, treat it as an architectural reference and a source to port (a thin service around the Docker API + a Laravel queue driver/job middleware), not as composer require-and-go.

When to Consider This Package

Consider adopting (likely as a fork or port) when:

• You are on Symfony (or willing to port the pattern), the codebase is PHP, and the DI/console integration is genuinely valuable.
• You already operate Docker hosts and have ops maturity around images, registries, log shipping, and host capacity — but you are deliberately avoiding Kubernetes.
• Jobs require isolation or conflicting dependencies, or you need hard resource caps (CPU/memory/time) per job that a shared worker pool can't cleanly provide.
• Volume is moderate and tolerant of seconds of cold-start latency — batch, nightly, backfills, on-demand report generation.
• You can pin and vendor the dependency: lock Symfony/Docker API versions, accept that the upstream is effectively frozen, and assign an owner for patching, orphan-container cleanup, retries, timeouts, log capture, and secrets injection.
• MIT license fits your policy — it does, and permissive licensing is what makes the fork-and-harden route legally clean.

Look elsewhere when:

• You are on Laravel. Use Laravel Queues + Horizon for throughput, and if you need per-job isolation, build a small internal runner on the Docker API / Symfony Process (or a managed container service). A Symfony bundle will cost more to integrate than to reimplement.
• You already have Kubernetes — K8s Jobs / Argo Workflows is the supported, observable, battle-tested version of this idea.
• You are cloud-native and prefer managed — AWS Batch, ECS RunTask, Cloud Run Jobs, Azure Container Apps Jobs all give you this model with support contracts and no host fleet to babysit.
• You need active maintenance, security backports, or vendor SLAs. Last release 2022-08-21 with zero dependents means undiscovered compatibility debt; assume it will break on the next Symfony major and that you will fix it.
• You need high throughput or sub-second job latency — a container per job is the wrong economics at that scale.
• You need auditability, multi-tenant fairness/quotas, or billing-grade job accounting — those are product features you'll build, not inherit.

How to Pitch It (Stakeholders)

One-liner for execs: An MIT-licensed, open-source Symfony bundle that runs each background job inside its own throwaway Docker container — giving us isolation, per-job dependencies, and hard resource limits without adopting Kubernetes. It's free, and it's a prototype-grade starting point, not a supported product.

What it buys us: a validated pattern for the class of work that keeps breaking our shared workers — jobs that need different runtimes or pinned dependencies, jobs that can be resource-hungry or untrusted, and jobs we'd rather not let touch the app process. The container-per-job model also gives us clean failure domains and simple cleanup semantics.

What it costs us: everything operational. The project has 19 stars, zero dependents, and no release since August 2022. Adopting it means we own it: compatibility with future Symfony/Laravel and Docker API versions, observability, retries and dead-letter handling, timeout enforcement, log aggregation, secret injection, and orphaned-container reaping. Licensing is permissive (MIT), so forking is legitimate and low-risk legally.

The ask: a 1–2 week engineering spike to fork it, pin versions, and run two representative jobs (one isolated-dependency job, one resource-heavy job) end to end. Gate the decision on: cold-start latency acceptable? Ops burden estimated in eng-days per quarter? If the spike is clean, we adopt the pattern internally and own a small, well-bounded runner; if not, we go managed (Batch/Cloud Run Jobs) or stay on standard queue workers. Do not position this as a production dependency in any roadmap or commitment until the spike closes.