Win32Servicebundle Laravel Package

Product Decisions This Supports

• Windows deployment strategy for PHP worker processes. Win32ServiceBundle wraps the win32service PHP extension so a Symfony Console command (queue worker, scheduler loop, long-running consumer) can be registered, started, stopped, and monitored as a native Windows Service. This is the decision point for "how do our background jobs run on Windows Server?" — and it is the only mature, maintained OSS answer in the PHP ecosystem.
• Build vs. buy vs. avoid. Building this in-house means writing C-level or sc-based service wrappers plus recovery/restart policy, event log integration, and signal handling. Adoption is almost always cheaper than building; the realistic alternative is avoiding the problem by hosting workers on Linux containers.
• Target-market / platform commitment. Using this package is a de facto commitment to supporting Windows Server as a first-class deployment target. That decision cascades into CI matrix (Windows runners), installer design, support burden, and documentation. Release v2.1.0 tells you the maintainers are keeping the platform alive: PHP 8.4 and 8.5 in the test matrix, and Symfony 7.4 compatibility, both landed in this release.
• Roadmap gating on PHP/Symfony upgrades. Because this release adds PHP 8.4/8.5 test coverage and Symfony 7.4 support, it unblocks a PHP-version upgrade on Windows hosts that would otherwise be pinned by an unmaintained service wrapper. This is a concrete "can we upgrade?" input for the platform-version roadmap.
• Laravel-specific use cases (with a caveat). Laravel's queue:work, schedule:run, Horizon, and custom Artisan commands are the natural payloads. However, this is a Symfony bundle, not a Laravel package — there is no service provider, no config/win32service.php, and no published Laravel integration. Realistically you would consume the underlying win32service extension plus Symfony Console directly, or write a thin Laravel adapter yourself. Treat this as "the reference implementation of the hard part," not a drop-in Laravel dependency.
• Ops/observability decisions. Whether service lifecycle events route into Windows Event Log, how restart-on-failure policy is configured, and whether crash-only restarts are acceptable for your worker semantics (at-least-once vs. exactly-once) all get decided here.

When to Consider This Package

Adopt when:

• You must run PHP background workers, schedulers, or daemons on Windows Server (on-prem, customer-managed, or regulated environments where Linux is not permitted).
• Your application is Symfony-based, or you are willing to manage the Symfony Console dependency inside a Laravel app.
• You need native service semantics — start on boot, run as a service account, restart on failure, no interactive RDP session required. A scheduled task or start /b php artisan queue:work is not equivalent and will not survive reboots or logoffs reliably.
• You are on, or planning to move to, PHP 8.4/8.5 or Symfony 7.4 and need a wrapper that is tested against those versions.
• Your team has Windows sysadmin capability to configure service accounts, ACLs, and Event Log access.

Look elsewhere when:

• Windows is not a required target. On Linux, systemd units, Supervisor, or containers are simpler, better documented, and require no extension. Do not add this dependency speculatively.
• You need a pure-Laravel, zero-friction install. No Laravel service provider exists; expect to write glue code and own it.
• Your workers are short-lived or idempotent-per-invocation — Windows Task Scheduler is a lower-complexity fit.
• You need container-native orchestration. This package is architecturally opposed to containerized deployment; running a Windows Service inside a container is an anti-pattern.
• The win32service extension cannot be installed in your environment (shared hosting, restricted php.ini, non-privileged service account) — the bundle is inert without it.
• You require vendor-backed SLAs. This is community-maintained; note that this release is almost entirely dependabot bumps plus one compatibility PR, which signals maintenance rather than active feature development.

How to Pitch It (Stakeholders)

For executives: We have a small, stable dependency that lets our PHP application run as a proper Windows Service — meaning our background jobs start automatically at boot, run under a service account without anyone logged in, and recover from crashes. The alternative is building and maintaining a bespoke Windows wrapper, which we would own forever. The new release (v2.1.0) is a maintenance release: no breaking changes, no new features, no deprecations. It adds PHP 8.4 and 8.5 to the test matrix and adds Symfony 7.4 compatibility, plus routine CI dependency bumps. Practical effect: our PHP upgrade path on Windows is not blocked by this dependency. Risk is low and unchanged.

For engineering: v2.1.0 is a compatibility and CI release. Changes: actions/cache 4→6, actions/checkout 4→7, PHP 8.4/8.5 added to the test matrix, Symfony 7.4 compatibility (PR #23, new contributor). No API changes, no breaking changes, no deprecations. Safe to bump as a routine minor upgrade; no migration work, no code changes expected. Two caveats worth stating plainly: this is a Symfony bundle, so there is no Laravel service provider — integration is via the win32service extension and Symfony Console, and we own any Laravel glue. And the release is dominated by automated dependency bumps, which is a reasonable maintenance signal but not evidence of active feature investment; plan for the possibility that we are the ones fixing anything that breaks on future PHP versions. Verify the upgrade on a Windows runner in CI, not just Linux.