Heroku Scheduler Bundle Laravel Package

Technical Evaluation

Architecture fit: This is a Symfony bundle (mczolko/heroku-scheduler-bundle), not a Laravel package, despite the framing. Laravel ships its own first-class scheduler (App\Console\Kernel::schedule(), schedule:run, withoutOverlapping, onOneServer). The bundle's integration model is Symfony's Bundle + DI container registration, which does not map onto Laravel's service container or package auto-discovery. The mismatch is structural, not cosmetic.

Integration feasibility: Low as a direct dependency. Adopting it inside Laravel would mean pulling Symfony components into a Laravel app and hand-wiring a bundle that Laravel's kernel never boots. The realistic path is to treat it as a reference implementation and reimplement its behavior in a Laravel console command — the bundle's actual surface area is almost certainly a thin wrapper around invoking console commands from Heroku Scheduler, so porting is cheaper than adapting.

Technical risk: High.

• Last release 2016-03-17 — over eight years unmaintained.
• 1 star, 0 dependents — no battle-testing, no downstream signal, no community.
• Composer constraints are likely PHP 5.x / Symfony 2.x era and will conflict with modern Laravel (PHP 8.x, Symfony 6/7 components).
• No visible CI, tests, or security posture; CVEs would go unpatched.
• Supply-chain risk is low (tiny package), but bit-rot risk is near-certain.

Key questions:

• Does the bundle do anything beyond wrapping heroku scheduler invocation of console commands?
• What PHP/Symfony versions does composer.json actually pin, and does it resolve against our Laravel version?
• Who owns scheduling in our architecture — the platform (Heroku Scheduler add-on) or the application (Laravel scheduler)? This decision dominates the build-vs-buy call.
• What is the real job inventory: count, cadence, overlap requirements, idempotency, retry semantics?
• Is the target app actually Symfony (in which case the framing is wrong and a native-console migration is the answer), or Laravel (in which case this package is out of scope)?

Integration Approach

Stack fit: Non-fit for Laravel. The idiomatic pattern is Laravel's native scheduler driven by the Heroku Scheduler add-on calling php artisan schedule:run on a one-off dyno. That gives us overlap control, per-job timeouts, and observability without a third-party bundle.

Migration path:

• If we inherit a Symfony app using it: migrate the scheduled entrypoints to native Symfony console commands invoked directly by Heroku Scheduler, then remove the bundle. The bundle is doing orchestration the platform already provides.
• If we are Laravel: do not adopt. Implement scheduling in Console\Kernel and let Heroku Scheduler only tick schedule:run.

Compatibility: Must verify Composer resolution against PHP 8.x and the Symfony component versions Laravel 10/11 already ship. Expect conflicts; do not force --ignore-platform-reqs to make it install.

Sequencing:

1. Inventory all scheduled jobs, cadences, and overlap/idempotency requirements.
2. Decide scheduler ownership (platform vs app) and document it as an ADR.
3. Prototype the Laravel-native path against a staging Heroku app (one-off dyno + schedule:run).
4. Decommission the bundle / decline adoption; record the decision.

Operational Impact

Maintenance: Effectively unmaintained upstream. Any fork becomes ours to own in perpetuity — full cost of ownership, zero upstream leverage. This is the dominant operational fact.

Support: No vendor, no community (1 star, 0 dependents). Knowledge is entirely internal; bus factor is whoever wrote the port.

Scaling: Heroku Scheduler granularity is coarse (10-minute / hourly / daily) and runs on ephemeral one-off dynos. Concurrency, overlap, and distributed locking must be handled by us. Laravel's withoutOverlapping() and onOneServer() are strictly better primitives than anything this bundle can offer.

Failure modes:

• Silent failure: Heroku Scheduler has weak retry/alerting; jobs can fail without paging anyone.
• Overlap/duplication: long-running jobs colliding with the next tick, causing double-processing.
• Platform drift: PHP/runtime upgrades on Heroku breaking a 2016-era dependency.
• Config drift: schedule defined in the Heroku dashboard diverging from code, with no diff or review.
• Timeout truncation: dyno termination mid-job with no resumption.

Ramp-up: Trivial in complexity terms — the package is small and the domain (scheduled console jobs) is well understood. The risk is abandonment, not learning curve. Reimplementation effort is realistically under two engineer-days, which makes "port it ourselves" strictly cheaper than "adopt and maintain a dead dependency."