- Can I use kmj/cronbundle in a Laravel application?
- Not in practice. KMJ CronBundle is a Symfony 2.x bundle that boots through AppKernel and wires itself into the Symfony dependency injection container, extension points Laravel does not have and cannot emulate. Composer also refuses to install it next to any supported Laravel release because of conflicting Symfony version constraints. Laravel's built-in scheduler covers the same use case with stronger guarantees.
- Does KMJ CronBundle support Laravel 11 or Symfony 6/7?
- No. The bundle pins symfony/symfony to the ~2.x range, while Laravel 10, 11 and 12 require Symfony components at ^6 or ^7, so the dependency graph is unsatisfiable. Symfony 2.x reached end of life in November 2018, meaning there is no upstream patch path even for the framework the bundle actually targets. There is no supported combination of this package and a modern Laravel or Symfony application.
- What does KMJ CronBundle actually do with the system crontab?
- It lets you declare tasks with standard cron expressions in bundle configuration, then rewrites the host user's crontab by shelling out to the crontab binary, and exposes a console command that runs the jobs that are due. That means scheduling state lives on the server rather than in your application code. This is the inverse of Laravel's model, where schedules are declared in-app and a single schedule:run tick is installed once by infrastructure.
- How do I install kmj/cronbundle with Composer?
- Running composer require kmj/cronbundle only resolves inside a legacy Symfony 2 project, and even there the framework itself is unmaintained. In a Laravel project the install fails during dependency resolution, and forcing it with --ignore-platform-reqs produces a broken autoload and runtime. The package should not be installed as a dependency in a Laravel codebase.
- What is the Laravel equivalent of KMJ CronBundle's scheduling?
- Laravel's task scheduler. You declare jobs in routes/console.php on Laravel 11 and later, or in app/Console/Kernel.php on older versions, and a single schedule:run cron entry fires every minute. The framework adds withoutOverlapping() for mutual exclusion, onOneServer() for multi-node fleets, before and after hooks, failure events, and output capture routed to your logs. The only thing it does not do is write the crontab, which is correctly owned by infrastructure-as-code.
- How do I migrate from KMJ CronBundle to Laravel's scheduler?
- For a legacy Symfony 2 app still on the bundle, freeze first and migrate second: pin the dependency, containerize to capture the current PHP and Symfony versions, and extract the live crontab into configuration management before changing anything. Then rewrite each crontab line as a Laravel scheduled command with the equivalent cron expression, and replace the generated crontab entries with one schedule:run tick provisioned by Ansible, cloud-init, Helm, Terraform or a Docker entrypoint. For a greenfield Laravel application there is nothing to migrate at all.
- Is KMJ CronBundle maintained and safe for production?
- The maturity signals are uniformly negative: around 3 stars, 0 dependents, no evidence of CI or a security disclosure process, and a composite score near 0.045, all on top of an end-of-life framework. The operational risk is concentrated in privileged crontab writes, since the web or queue user needs crontab rights, which widens the blast radius of any application compromise. Known failure modes such as partial writes, duplicate entries accumulating across deploys, clobbered backup or log-rotation entries, and quoting bugs in generated lines are invisible to application-level tests.
- How do I run scheduled tasks in Laravel without touching the server crontab?
- Declare your jobs in the application and provision exactly one crontab line through your deployment tooling: * * * * * cd /path && php artisan schedule:run >> /dev/null 2>&1. That single line can be shipped by Ansible, cloud-init, Helm, Terraform or a Docker entrypoint, so no application code ever mutates host state. Schedules then stay version-controlled with the code and behave correctly in containers and autoscaled environments.
- Why does Composer fail when requiring kmj/cronbundle alongside Laravel?
- Composer cannot satisfy both constraint sets at once: the bundle requires symfony/symfony in the ~2.x range while every supported Laravel release requires Symfony components at ^6 or ^7. The only ways around it are --ignore-platform-reqs hacks or a fork that rewrites the constraints. A fork means inheriting indefinite maintenance of privileged code that writes to the host crontab.
- Are there better maintained alternatives to KMJ CronBundle?
- For Laravel applications the native scheduler is the strongest option and needs no third-party package for declaring and running cron-style jobs. If you only need to parse or evaluate cron expressions, the standalone dragonmantank/cron-expression library handles that safely and is already a Laravel dependency. For schedules that are tenant-dynamic or infrastructure-driven, a Kubernetes CronJob or a managed scheduler plus a queued job is usually a better fit than rewriting crontabs from application code.