Daemons Bundle Laravel Package

Product Decisions This Supports

• Platform fit check (decide first): this is a Symfony bundle, not a Laravel package. If the product runs on Laravel, this is only relevant as prior art for how another framework solved command daemonization — not as an installable dependency. That single fact should close most Laravel-side evaluations before engineering time is spent.
• Build vs. buy vs. operate: the underlying decision is "how do we keep a long-running PHP process alive?" The realistic options are (a) adopt a process supervisor (Supervisor, systemd, Kubernetes restart policy), (b) use a framework-native worker (Laravel queue:work + Horizon, Symfony Messenger consumers), or (c) write/bundle an in-process daemon loop like this one. This package represents option (c) and is useful mainly as a reference point when arguing for (a) or (b).
• Feature scoping for background work: if a roadmap item implies "poll an external API every N seconds," "hold a socket open," or "consume a queue," this package frames the cheapest possible version of that feature — a while(true) console command. It sharpens the conversation about what "cheap" costs later in reliability and observability.
• Roadmap risk register: adopting an unmaintained, near-zero-signal dependency for anything on the critical path creates an ownership obligation. Documenting that trade-off — and rejecting it — is itself a valuable decision record for the team.
• Use cases where the category is legitimate: internal admin tooling, one-off integration scripts, short-lived migration helpers, local dev parity for a production worker. Not customer-facing SLAs, not billing, not anything with an on-call rotation.

When to Consider This Package

Consider it (or the pattern it encodes) only when all of the following hold:

• The codebase is Symfony, and the team wants a minimal, in-repo daemon loop rather than adding Supervisor as operational surface area.
• The workload is low-stakes and internal — no uptime commitment, failures are tolerable and manually recoverable.
• Deployment is single-host, non-containerized, where a PID file and a forked process are sufficient and nothing will reap the process unexpectedly.
• The team is willing to own and fork the code, because the project shows no adoption signal (0 stars, 0 dependents, score 0) — treat it as source you are adopting, not a vendor you are relying on.

Look elsewhere when:

• You are on Laravel. Use queue:work / Horizon with Supervisor. This bundle does not apply.
• You need reliability primitives: graceful shutdown on SIGTERM, restart backoff, crash-loop protection, memory-leak guards, health checks, structured logs, metrics. A process supervisor gives these for free; an in-process loop does not.
• You deploy to containers or Kubernetes. The orchestrator already is your supervisor; a self-daemonizing PHP process fights the platform and breaks rolling deploys.
• You need concurrency, retries, prioritization, or rate limiting. That is a queue system's job, not a daemon's.
• Anything customer-facing or revenue-affecting. The dependency-risk profile does not support an SLA.

How to Pitch It (Stakeholders)

Executive summary: We evaluated edo/daemons-bundle, a small Symfony bundle for turning console commands into long-running background processes. Two conclusions. First, it is not applicable to our Laravel stack — it targets Symfony's console component, so adopting it would mean porting it, not installing it. Second, even on Symfony we would not recommend it: the project has no measurable adoption (zero stars, zero dependents, unrated) and no evidence of maintenance, which makes it an ownership liability rather than a dependency. Recommendation: do not adopt. It does, however, usefully frame the real decision — how we run background work.

For engineering: the reliable pattern is a framework-native worker process kept alive by an external supervisor (Supervisor/systemd, or the container orchestrator), which gives us restarts, graceful shutdown, backoff, and log capture without custom code. Where we need that behavior today, use queue:work/Horizon. If a specific Symfony service ever needs a bespoke loop, we should write and own ~50 lines in-house rather than take on an unmaintained third-party bundle — same effort, full control, no supply-chain risk.

Ask: no budget, no procurement, no pilot. Close the evaluation, and if background processing is on the roadmap, spend the next planning cycle on a supervisor + queue architecture decision instead.