imper86/jobby-cron-bundle
A Symfony bundle that integrates the Jobby cron manager, letting you define and schedule cron jobs in application configuration, run them from a single crontab entry, and keep job definitions versioned with your code.
Architecture fit — poor for a Laravel codebase. The single most important finding: this is a Symfony bundle, not a Laravel package. It wraps jobbyphp/jobby, a cron-job manager that replaces many crontab entries with one (* * * * * php jobby.php) and handles per-job scheduling, locking, output capture, and failure emailing. Laravel already ships a functionally overlapping scheduler (schedule:run, withoutOverlapping(), onOneServer(), schedule:list, schedule:test) with better observability. Symfony bundles register via bundles.php and compiler passes — a mechanism Laravel does not have — so consuming this package in a Laravel app requires manually re-implementing its service wiring, which erodes most of the value it would have provided.
Integration feasibility — low value per unit of effort. To use it in Laravel you would either (a) pull in the bundle and hand-wire its DI configuration through a Laravel service provider, effectively reimplementing the bundle, or (b) skip the bundle and depend on jobbyphp/jobby directly, which is a plain PHP library and composes cleanly behind a Laravel console command or a thin service class. Option (b) is the only credible path, and at that point the package under evaluation is out of the picture entirely.
Technical risk — high, driven by adoption and maintenance signals. 6 stars, 0 dependents, and a composite score of 0.06 indicate essentially no production usage to learn from. A Symfony bundle of this type is typically a thin configuration layer; it will lag Symfony/PHP releases and will not receive security or compatibility patches at a cadence a production dependency requires. Jobby itself is more established but is a low-activity project; its locking model is filesystem-based, which has direct multi-node implications (see Operational Impact). The imper86 bundle should be treated as abandoned-by-default until evidence says otherwise.
Key questions
schedule:run + withoutOverlapping() + onOneServer() does not?Stack fit. Two distinct scenarios, and the recommendation differs by scenario. In a Symfony application, the bundle is idiomatic and low-friction: register the bundle, declare jobs in YAML, point one crontab entry at the jobby console command. In a Laravel application, do not adopt the bundle. Use jobbyphp/jobby directly if jobby semantics are genuinely required, wrapped in an application-owned console command so the dependency is isolated behind one seam. If jobby semantics are not required, stay on the native Laravel scheduler.
Migration path. Recommended sequence: (1) inventory every existing crontab entry, its schedule, overlap tolerance, and failure-notification destination; (2) build a proof-of-concept in a non-production environment that runs three representative jobs — one long-running, one that can overlap, one flaky — through the chosen mechanism; (3) compare against the native scheduler on locking behavior, log capture, and failure signal; (4) decide and document. The PoC is cheap and should gate everything else. Do not begin by adopting the bundle.
Compatibility. Verify the bundle's composer.json constraints against the platform's PHP and framework versions before any design work — a mismatch on a bundle this low-traffic is likely and is disqualifying. Confirm jobby's own supported PHP range separately, since it is the component doing the real work. Also verify behavior in containerized deployments where the filesystem may be ephemeral or per-pod.
Sequencing. Locking semantics must be settled before job definitions are migrated — it determines whether the mechanism is viable at all on multi-node infrastructure. Notification/alerting integration should follow, then configuration migration, then decommissioning of legacy crontab entries. Keep the old crontab entries live but disabled for one full scheduling cycle as a rollback path.
Maintenance. The realistic burden is not "keep the dependency updated" but "own the dependency." With 0 dependents and negligible community, expect to carry patches, PHP-version bumps, and framework-compatibility fixes ourselves. Budget a fork or a vendored copy. This is acceptable for a ~200-line glue layer and unacceptable for anything load-bearing across teams.
Support. No vendor, no community, effectively a bus factor of one upstream maintainer. Internal support means one or two engineers who understand jobby's locking and exit-code behavior. That knowledge must be documented, not held individually — otherwise on-call cannot triage scheduled-job failures.
Scaling. The critical constraint: jobby's locking is file-based, so it is safe only on a single host or across hosts sharing a reliable shared filesystem. On horizontally scaled or autoscaled infrastructure with ephemeral containers, file locks do not coordinate and will silently allow duplicate execution. If the platform runs more than one instance, this is a blocker — native scheduler locking backed by a shared cache store is the correct answer, and it is the strongest single argument against jobby in a Laravel context.
Failure modes. Watch for: cron entry silently absent after a host rebuild (jobs stop, nothing alerts); stale lock files after a killed process, blocking future runs; unhandled non-zero exit codes treated as success; output discarded because logging is not wired to the platform's log sink; email-based failure notification failing silently or landing in a shared inbox nobody reads; and version drift on PHP upgrades breaking the jobby bootstrap. Each of these should map to an explicit detection or alert before go-live.
Ramp-up. Mechanically low — jobby's model is simple and a competent engineer is productive in a day. The real ramp-up is in the surrounding operational discipline: lock semantics, exit-code contracts, alert routing, and knowing which jobs are overlap-safe. Treat the proof-of-concept and the runbook as the actual deliverables; the package itself contributes little either way.
How can I help you explore Laravel packages today?