- What does jmose/command-scheduler-bundle actually do?
- It is a Symfony bundle that adds cron-style scheduling to console commands. You define recurring jobs in YAML or PHP configuration with standard cron expressions, arguments, and options, then run a single scheduler command that executes everything currently due. Because schedules live in configuration files, they can be committed to version control and deployed consistently. Version 3.0.x adds Symfony 5 support on top of the previously supported 3.4 and 4.x lines.
- Does this package work with Laravel?
- No. Despite being frequently miscategorized in package tooling, this is a Symfony bundle with no Laravel service provider, facade, config publishing, or awareness of Illuminate\Console\Scheduling\Schedule. Booting a Symfony kernel inside a Laravel app means reconciling two Doctrine and DBAL stacks, duplicating container wiring, and mounting a Symfony-only admin UI. For a Laravel codebase the realistic path is extracting the pattern, not installing the package.
- How do I install and set up the bundle?
- Install it with Composer and register the bundle in your Symfony kernel. You then generate the Doctrine schema for the CronJob table, add a single system crontab entry that runs the scheduler command every minute, and optionally enable the Sonata-based admin panel. The supported band is roughly Symfony 3.4 through 5.x.
- Which Symfony and PHP versions are supported?
- Version 3.0.x adds Symfony 5 support, widening the target range from 3.4 to 5.x. Symfony 6 and 7 are not addressed at all, which means the bundle is roughly one major version behind current Symfony releases. Before adopting it, verify the exact PHP matrix the tag was tested against, since there is no visible CI configuration proving support for PHP 8.x.
- Why run one crontab entry instead of adding a line per job?
- The bundle uses a single-minute tick: one system crontab entry polls a Doctrine-backed CronJob table, evaluates each job's cron expression, and spawns the commands that are due as subprocesses. That keeps the server crontab minimal and lets schedules be edited at runtime. Architecturally it is very similar to Laravel's schedule:run, but implemented independently and coupled to Doctrine.
- How do I define a scheduled job in YAML configuration?
- Each job entry specifies the console command to run, its cron expression, and any arguments or options the command needs. Because the definition is plain configuration, it diffs cleanly in code review and ships with your deployment. Jobs can also be created or edited at runtime from the admin panel and stored in the database.
- Is the admin panel safe to expose in production?
- Any web UI that stores and executes arbitrary console commands is functionally a remote-execution console, so treat it as a privileged surface. Authentication, CSRF protection, role separation, and network ACLs or IP allowlisting are tier-one controls that must not be skipped. Command arguments are stored in plaintext and are readable by anyone with panel access, so never pass API tokens, passwords, or sensitive identifiers as arguments.
- What are the alternatives to this bundle?
- If you are on Laravel, use the framework's built-in scheduler with schedule:run and a single crontab entry. On Symfony or plain PHP you can use system cron directly, or reproduce the core behavior in roughly 200 lines on top of dragonmantank/cron-expression. The bundle's real differentiator is database-driven, runtime-editable schedules plus an admin UI, not the scheduling itself.
- Is this package actively maintained?
- Read the 3.0.x releases as a single maintenance burst rather than a revival. Symfony 5 support landed roughly a major version late, Symfony 6 and 7 are unaddressed, and there is no published security policy or evidence of a steady release cadence. Pin exact versions, commit your lockfile, and consider an internal mirror or vendored fork if you depend on it.
- What dependency risks should I check before installing?
- Version 3.0.0 replaced the abandoned mtdowling/cron-expression with dragonmantank/cron-expression, which resolves the old day-one Composer collision. Check the pinned constraint carefully, because if it resolves to ^1.0 or ^2.0 it still conflicts with the ^3.0 line that current Laravel and Symfony applications carry. Note also that 3.0.0 was yanked from Packagist almost immediately after publication, so tags in this repository are not treated as immutable and downstream installs can break without warning.