- Does Jobby work with Laravel, or should I just use Laravel's scheduler?
- Jobby is framework-agnostic and predates Laravel's Schedule facade, so it can run inside a Laravel project but largely duplicates what the framework already provides. Laravel's scheduler already offers withoutOverlapping, onOneServer, output capture, and email hooks, and running both creates two competing scheduling authorities. Prefer Jobby only where jobs must stay as existing plain CLI commands and the framework scheduler is not an option.
- How do I install Jobby with Composer in a Laravel or plain PHP project?
- Install it with composer require hellogerard/jobby, then register a single crontab entry that calls the jobby binary, typically vendor/bin/jobby, every minute. Define all scheduled tasks in one YAML or JSON manifest, with each job specifying its command, cron expression, enabled flag, log file, and lock settings. Confirm the binary path and the pinned PHP version on the host before going live.
- Is Jobby compatible with PHP 8 and Laravel 9, 10, or 11?
- The last tagged release is 2020-07-25, which predates PHP 8.x and Laravel 9, 10, and 11, so compatibility is not guaranteed. Run a compatibility spike against the exact PHP minor and the Symfony Console and Process versions in your lockfile before adopting it. Add the package to a dependency-audit gate, and expect to vendor and maintain a fork if the spike fails.
- How does Jobby prevent overlapping job runs?
- Jobby writes a lock file for each job before execution and skips the run if that lock is already held, which prevents overlapping executions on a single host. Locking depends on filesystem behaviour, so NFS or other network-mounted volumes are a known source of stale locks and silent overlap. It is a per-host mechanism, not a distributed lock.
- Does Jobby work across multiple servers or an autoscaling fleet?
- No. Jobby's overlap protection is file-based and per host, so on an autoscaled fleet each instance keeps its own locks and the overlap guarantees quietly break. For multi-server deployments use Laravel's onOneServer with a shared cache lock in Redis or the database, or another distributed lock. Jobby fits a single long-lived application server much better.
- How does Jobby capture job output and logs?
- Each job can declare an output log path, and Jobby redirects stdout and stderr there so output is captured outside the cron mail spool. You still need an external logrotate policy, because these files grow without bound otherwise. The captured exit codes and error output are also what feed the failure email alerts.
- Can Jobby email me when a job fails?
- Yes. Per-job settings let Jobby send an email when a job fails or produces error output, so you can alert on critical jobs without wrapping every command yourself. Delivery depends on the host's mail transport, such as sendmail, so test that path on the target server first. Pair alerts with log capture so failures are both notified and retained for review.
- How do I safely migrate an existing crontab to Jobby?
- Treat it as a strangler migration: inventory the current crontab, classify each entry by criticality and runtime, and port a small cohort of low-risk jobs first, such as log rotation or cache warmers. Run Jobby in parallel with legacy cron on non-overlapping schedules, diff outputs and exit codes, then cut over job by job. Keep the original entries commented and reversible until a full business cycle, including monthly and quarterly jobs, has passed.
- Is Jobby safe to run in production when it executes commands from a config file?
- Jobby runs shell commands and PHP scripts defined in a manifest, so treat that config file as a remote-code-execution surface with tight permissions and the same review posture as application code. User switching requires the cron process to hold privileges to change users, which notably increases blast radius on shared hosts. Because the package is unmaintained, transitive dependencies cannot be patched upstream, so pin versions and audit them.
- What are the alternatives to Jobby for scheduling PHP jobs?
- Inside Laravel, the built-in scheduler with Schedule::command, withoutOverlapping, onOneServer, and output and email handling is the lower-risk default. For framework-agnostic PHP, Symfony Scheduler with Messenger, or plain cron combined with a lockfile library, covers most needs. Jobby stays reasonable for consolidating a sprawl of hand-edited crontabs on a single legacy server.