Cron Bundle Laravel Package

Technical Evaluation

Architecture fit. okvpn/cron-bundle is a Symfony bundle, not a Laravel package. It assumes a Symfony kernel, its service container, console commands, and (per its design) Doctrine for persisting cron job state. It is architecturally incompatible with Laravel's container, Eloquent/ORM, and Artisan scheduler by default. Adopting it in a Laravel codebase means either co-hosting a Symfony app or writing a non-trivial adapter — neither is a TPM-level "drop-in" decision.

Integration feasibility. Low for a Laravel-primary stack. The bundle's value proposition — a long-lived PHP process that polls a schedule, enforces locking, and optionally offloads tasks to a message queue — overlaps almost entirely with Laravel's first-party Schedule facade plus queues + Horizon. The differentiating features (Docker-friendly daemon instead of system crontab, DB-backed job tracking) are real, but Laravel teams usually get equivalent behavior from schedule:work in a container and withoutOverlapping().

Technical risk. High for the size of the dependency:

• Bus factor 1. 18 stars, 0 dependents, single-maintainer project. No signal of organizational backing.
• Staleness. Last release 2023-08-21; no evidence of active maintenance against current Symfony/PHP versions.
• Zero downstream adoption. 0 dependents means no public battle-testing; failure modes are undocumented in the wild.
• Doctrine coupling. The DB-backed lock/schedule state assumes Doctrine entities; forcing this into a Laravel app adds an ORM just for cron state.
• Security surface. A long-lived process that executes arbitrary registered tasks needs careful review of how tasks are registered, authorized, and isolated.

Key questions to answer before any commitment:

1. Is any part of the stack actually on Symfony, or is this being evaluated for a Laravel app?
2. What concrete capability is missing from schedule:work + queues that this bundle provides?
3. Who owns the fork if the maintainer goes dark?
4. Are we prepared to fork/vendor and maintain this ourselves?
5. Does the queue integration (RabbitMQ/AMQP) match our existing broker?

Integration Approach

Stack fit. Poor for Laravel; reasonable for Symfony 5/6-era apps that need to escape system crontab in containerized environments. For Laravel, the correct comparison is the native Illuminate\Console\Scheduling\Schedule + schedule:work (or schedule:run via a supervisor-managed worker), paired with Laravel queues and withoutOverlapping() / onOneServer() for locking.

Migration path (if Symfony is in scope). Replace system crontab entries with bundle-registered console commands in config/packages/okvpn_cron.yaml; introduce the Doctrine schema for job state; run the scheduler as a supervisor/systemd-managed daemon inside the container; enable queue offload only after the in-process path is proven.

Migration path (if Laravel is in scope). Do not adopt. Instead:

• Register scheduled tasks in routes/console.php (Laravel 11+) or Kernel::schedule.
• Use withoutOverlapping()->onOneServer() backed by the cache lock driver.
• Run php artisan schedule:work as a container sidecar or supervisor process.
• Offload heavy jobs to queues + Horizon.

Compatibility. Confirm against the target PHP version and Symfony major (the 2023 release implies Symfony 5.4/6.x territory). Cross-check the Doctrine ORM version constraint — this is the most likely conflict point in a modern stack. Verify container base image (Alpine vs. Debian) and whether the long-lived process survives SIGTERM gracefully.

Sequencing. If pursued at all:

1. Spike in a throwaway Symfony app to confirm the daemon + lock + queue behaviors.
2. Prove parity against a native Laravel scheduler prototype.
3. Only then decide whether to fork into a Laravel-flavored version — otherwise stop at step 2.

Operational Impact

Maintenance. The dominant risk. A single-maintainer package with no releases since Aug 2023 and zero dependents is effectively unmaintained for planning purposes. Treat any adoption as "we fork and own it," not "we consume it." Budget for a named internal owner and a quarterly review of upstream activity.

Support. No commercial support, no vendor SLA, community-only via GitHub issues. Escalation path is internal engineering. Document a fallback plan (revert to native scheduler) in the runbook.

Scaling. The design explicitly targets scaling via parallel workers and message-queue offload, which is sound. The bottleneck becomes the state store: every tick hits the database for job state, locking, and last-run bookkeeping. At high schedule density, expect DB contention on the lock table; plan for a dedicated schema/indexes and monitor lock wait times. Queue offload scales the execution but not the scheduling loop — the scheduler remains a single instance unless you shard schedules.

Failure modes to model and monitor:

• Daemon crash → missed runs; no automatic catch-up unless explicitly configured. Alert on heartbeat loss.
• Duplicate execution → lock-store failure or clock skew between container and DB. Enforce a single scheduler instance and a DB-synchronized clock.
• Overlap storms → long-running jobs backing up; cap concurrency and enforce per-task timeouts.
• Queue broker outage → tasks queued but never executed; dead-letter + lag alerts required.
• Silent schedule drift → no run-record for an expected task within its window; emit a "job did not fire" alert per critical task.
• Upgrade rot → PHP/Symfony bump breaks the bundle with no maintainer fix; maintain a fork branch.

Ramp-up. Low code volume but specialized context. Engineers need familiarity with Symfony's console/DI model, Doctrine schema migrations, supervisor/systemd process management, and broker semantics. Estimate a 3–5 day ramp for a senior PHP engineer new to the bundle, plus additional time if the Laravel-vs-Symfony context switch is in play. Total cost of ownership is dominated by maintenance and fork overhead, not initial integration.

Recommendation. Score of 0.34 with 18 stars and 0 dependents is consistent with "evaluate, do not adopt" for a Laravel stack. Use this package as a reference design for Docker-friendly scheduling, and implement the same pattern with Laravel's native scheduler and queue primitives. Revisit only if the organization standardizes on Symfony or commits an owner to maintain a fork.