Daemon Bundle Laravel Package

Product Decisions This Supports

• Feature feasibility: background work without a queue platform. If the roadmap item is "poll a third-party API / SFTP drop / legacy DB every 30 seconds," this package answers "can we ship that this sprint?" before you've committed to SQS, Redis queues, or a worker fleet. It gives you a daemon lifecycle (start, loop, graceful SIGTERM shutdown, memory ceiling, run-once flag for cron and CI) as a command base class.
• Build vs. buy for worker plumbing. This is the key decision it informs. The functional surface is small — a while loop, pcntl signal handling, a memory guard, and an event dispatcher hook. That is roughly a day of engineering to write and test. The package value is convention and precedent, not capability. A PM should price it as "a reference implementation we may vendor," not "a dependency we adopt." New in v9.0.0: the maintainer replaced the bundle's own handleSignal function with a ConsoleCommandListener class because it collided with the new handleSignal added in Symfony 7.3. That is precisely the subsystem a team would copy if they vendored the pattern — and it just broke against a framework minor release. Budget the port as "copy the shape, own the signal handling," and expect to revisit it whenever the framework moves.
• Framework-compatibility risk is now a tracked line item. v9.0.0 is a major bump that exists solely to fix a Symfony 7.3 incompatibility. Practically: v8.x and earlier are unsafe on Symfony 7.3+, and v9 requires a Symfony version where the listener-based approach is valid. Any decision to adopt carries a standing obligation to track Symfony minors — not a one-time install.
• Infra/staffing decision: do we require a process supervisor? Any daemon decision implies Supervisor, systemd, or a container restart policy. This package does not solve restarts, crash backoff, or multi-host distribution — so adopting it forces an explicit answer to "who restarts this at 3am?" That's a worthwhile forcing function to surface before the feature is sold.
• Cron strategy. Choosing sub-minute scheduling over cron is a real product decision (latency SLAs on sync freshness). A daemonized command is the cheapest way to buy that latency; the tradeoff is that you now own a long-lived process.
• Use cases it fits: legacy system pollers, webhook relay retries, cache/index warmers, low-volume internal event consumers, one-off backfill loops with resume-on-crash semantics.
• Dependency-vetting / risk posture. ~59 stars and 0 known dependents remain true, but the maintenance signal has improved: a prompt, correctly-versioned response to a framework change. Read this as "small but alive," not "abandoned." A PM can use it as the canonical example of "tactical dependency, isolated behind an interface, upgraded on a known cadence, no roadmap dependency on it."
• Framework-fit decision (flag this early). This is a Symfony bundle, not a Laravel package. There is no service provider, no Artisan integration, no config/ publish path for Laravel. For a Laravel codebase the decision shifts from "install it" to "port the pattern" — which reframes the whole build-vs-buy call. The v9.0.0 breakage is Symfony-specific and does not touch Laravel, but it does illustrate why a port should be written against Laravel's own signal handling rather than transcribed from this bundle's internals.

When to Consider This Package

Consider it when all of the following hold:

• Your application is Symfony Console-based (or you are willing to port ~100 lines into Artisan).
• You need one to a handful of long-running commands, not a worker fleet.
• You want graceful shutdown and a memory guard on day one, because your job leaks memory or holds open connections.
• You have (or will stand up) a supervisor — the bundle does not provide process resilience.
• The work is not latency-critical at scale and does not need at-least-once semantics, retries, dead-lettering, or backpressure.
• You can track the framework's minor releases. Pin to ^9.0 on Symfony 7.3+; treat v8.x as unsupported on 7.3 and later.
• You accept low community validation (~59 stars, 0 dependents) and are comfortable reading the source rather than the docs.

Look elsewhere when:

• You're on Laravel. Use queue:work with Horizon, or a scheduled command at everyMinute/everyFiveSeconds. Adding a Symfony bundle to Laravel is a net-new adapter layer for a commodity feature.
• You're pinned to an older Symfony and can't move to v9. Staying on v8.x means accepting a known incompatibility with 7.3+; that's a maintenance bet, not a stable state.
• You need horizontal scale, retries, or visibility. Symfony Messenger, Laravel queues + Horizon, or a managed broker already solve this with dashboards and ops tooling. Don't hand-roll a poller over a queue you already pay for.
• You need true concurrency. A single-process loop is one core. ReactPHP, Amp, Swoole, RoadRunner, or FrankenPHP worker mode are the right answer if throughput matters.
• You need observability out of the box — metrics, traces, per-job timing. You'd be writing that instrumentation yourself here.
• You need vendor guarantees. No dependents and a single-maintainer history means no support path; keep it out of the critical path or vendor the code.
• The requirement is really "run this occasionally." A cron entry is cheaper to own than a daemon and has fewer failure modes.

How to Pitch It (Stakeholders)

Executives: This is a small, MIT-licensed utility that lets PHP run a long-lived background command with clean startup, shutdown, and a memory cap. It is not a queue, not a scheduler, and not infrastructure — it's a coding convention plus about a hundred lines of loop and signal handling. Cost to adopt is low; cost to own is a supervised process, which we'd pay regardless of which library we pick. No license cost, no strategic lock-in. Vendor risk is real but smaller than it looked: still ~59 stars and no downstream dependents, effectively one maintainer — but the just-shipped v9.0.0 shows that maintainer responding quickly and correctly to a breaking framework change (Symfony 7.3 changed its signal handling and this bundle's approach collided with it). That is a good sign, and it is also a reminder that this dependency will require periodic version upkeep rather than "install once." Recommendation: don't budget it as a platform investment. Treat it as a tactical pattern — either port the loop into our own base command (preferred if we're on Laravel) or adopt it in a single bounded service we can replace in a day, pinned to ^9.0. The decision it should unblock is "do we need a broker, or is a poller enough for this feature?" — and for the specific use cases on the table, a poller is enough.

Engineering: The package is a Symfony bundle providing a DaemonCommand base class: loop with per-iteration events, signal handling for graceful shutdown, a memory-limit check, and a --run-once mode. It does not supervise, restart, distribute, retry, or instrument. v9.0.0 is a breaking change: the bundle's internal handleSignal function is removed and replaced by a ConsoleCommandListener class, because the old function conflicted with the new handleSignal introduced in Symfony 7.3. Upgrade to v9 if you're on 7.3+; do not mix v8.x with Symfony 7.3. For Laravel, expect to port the pattern rather than install the bundle — one class, one console command, one Supervisor program — and write the signal handling against Laravel's own facilities so this specific Symfony-internal collision can't reach us. Isolate it behind an internal interface so replacement with Messenger, Horizon, or Swoole is a config change, not a refactor. Budget half a day to read the source before committing; the value is in the shutdown and memory-guard details, which are the parts teams usually get wrong on the first attempt — and, as v9.0.0 demonstrates, the parts most exposed to framework churn.