Schedule Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for recurring-task orchestration: zenstruck/schedule-bundle is a thin, opinionated layer over Symfony's Scheduler component and Messenger. Adopting it is effectively a decision to not hand-roll a cron wrapper, a "run this command every N minutes" registry, or a bespoke task-dispatch console command.
• Roadmap sequencing toward Symfony 8: v1.9.0 adds Symfony 8 support and clears deprecations. This directly de-risks a platform-upgrade epic — scheduling infrastructure is one of the dependency chains that typically blocks a major framework bump, and this release removes it from the critical path.
• Feature decisions around operational visibility: The bundle's value is as much in schedule:list / schedule:run-style introspection as in execution. It supports decisions like "do we need an admin UI showing upcoming runs?" — the answer is often "no, we can surface the CLI output."
• Consolidation of ad-hoc cron entries: Every existing crontab line that invokes bin/console app:foo is a candidate for migration. Use this as a backlog item to inventory and migrate recurring jobs into version-controlled PHP, which improves reviewability and testability.
• Multi-tenant / per-entity scheduling: Where schedules must be derived from database rows (per-customer digests, per-account syncs), a schedule provider that can be programmed in PHP — rather than static crontab — unlocks product features that cron cannot express.
• Use cases that fit well: periodic cleanup/purge jobs, digest and notification emails, sync/polling workers, retry and escalation timers, report generation.

When to Consider This Package

Adopt when most of the following hold:

• The application is Symfony-based (this is a Symfony bundle, not a Laravel package — Laravel teams should use Laravel's built-in scheduler, which covers the same ground with first-class framework support).
• You already use, or are willing to use, Symfony Messenger — the scheduler dispatches tasks as messages, so a transport and worker process are part of the operating model.
• Your scheduling needs are single-node or idempotent-tolerant. The bundle schedules; it does not provide distributed locking, leader election, or exactly-once guarantees.
• You want schedules in code and in version control, testable and reviewable, rather than in a crontab on a hand-configured host.
• You're on a supported Symfony version and want a dependency that tracks current framework releases (v1.9.0 explicitly targets Symfony 8, so it won't become the thing that pins you to Symfony 7).

Look elsewhere when:

• Laravel or framework-agnostic — use the framework's scheduler, or a standalone cron library.
• You need high-availability / at-most-once execution across replicas. You need a lock store (e.g. a shared cache lock) layered on top, or a different tool entirely.
• Scheduling is infrastructure-critical and low-tolerance (billing runs, financial settlement). Prefer a durable workflow/job engine with retries, dead-letter handling, and audit history rather than a scheduler + Messenger.
• You need dynamic, user-editable schedules without deploys — possible via a DB-backed provider, but the bundle offers no admin surface; you'd build and own that.
• You want zero additional dependencies — the capability gap versus a plain crontab is real but modest, and the operating cost of running Messenger workers is not free.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, low-risk dependency that lets us define all recurring background jobs — nightly cleanups, digests, syncs, reminders — in version-controlled code instead of server crontabs. That means changes go through code review and CI, jobs become testable, and we stop depending on undocumented hand-edited server config. The v1.9.0 release adds support for the next major Symfony version and clears deprecation warnings, so adopting it now does not create a blocker for our upcoming framework upgrade. Cost is minimal: one Composer dependency plus running the Messenger worker we already operate.

For engineering leadership: It's a ~thin bundle over Symfony Scheduler + Messenger, maintained in the Zenstruck ecosystem. Interfaces are small (a ScheduleProvider plus attributes), migration is incremental — one crontab line at a time — and reversible. v1.9.0 is a compatibility and hygiene release: Symfony 8 support, deprecation fixes, dev-dependency bumps. No breaking changes, no new API surface, nothing requiring code changes on our side; it's a safe composer update.

For the engineering team: Treat it as a scheduling declaration layer, not an execution-guarantee layer. We still own worker supervision, lock strategy for anything that must not double-run, and observability. Recommendation: pilot on non-critical jobs first, and standardize on a shared lock for anything money- or customer-visible.