Static Php Cli Laravel Package

Product Decisions This Supports

• Distribution model for PHP CLI tooling. Choose between (a) a Composer package that requires the customer to have PHP + extensions installed, (b) a container image, or (c) a single self-contained binary. This package makes (c) a credible option, which directly changes onboarding docs, support load, and the "install PHP 8.x and enable these extensions" prerequisite.
• Build vs. buy on the compile pipeline. It is a build orchestrator (spc) that compiles PHP with a curated static extension set and can bundle a project into one artifact. Adopting it is a "buy" decision that avoids owning a ./configure/cross-compile matrix — but you still own the artifact, signing, and release process.
• Roadmap of supported targets and extensions. The PHP minor versions, architectures (x86_64/aarch64, glibc/musl, macOS), and extension catalog you require become your compatibility contract. Anything missing is a scoped roadmap item rather than an unknown. The 2.8.5 release added deepclone and decimal, which is the kind of incremental catalog growth to expect: extensions arrive steadily, but you should still plan for the ones you need to be missing at first.
• Use-case prioritization. Best fits: ops/DevOps CLIs, migration or data-fix scripts run on machines you don't control, on-prem/air-gapped installers, single-artifact CI tooling, developer tools (phpstan-style), and small "appliance" deployments. It does not fit application hosting.
• Support-cost reduction as a product goal. Eliminates distro PHP packaging differences and lets you serve enterprise customers who ban Docker — a segment-access decision, not a feature decision.
• Toolchain risk is now a named line item. 2.8.5 removes the workaround for Zig < 0.16 and fixes an aarch64 shared-extension segfault under Zig 0.16.0, i.e. the build pipeline has a floating native-toolchain dependency you must pin (Zig, Clang) alongside PHP itself. Budget for that in the release-engineering owner's remit.
• Caveat for the roadmap conversation: the low opportunity score and zero dependents indicate limited ecosystem pull and near-zero monetization leverage. Treat this as internal infrastructure that lowers cost and unblocks a segment, not as a product bet in itself.

When to Consider This Package

Adopt when:

• You ship a PHP CLI that must run on machines you don't administer, where installing PHP and extensions is friction or a hard blocker (locked-down enterprise, air-gapped, jump hosts).
• You need a pinned, reproducible PHP runtime with a known extension set across Linux x86_64/aarch64 and macOS.
• You want to shrink or remove a container runtime as a distribution requirement.
• Your extension needs are on the popular list (openssl, curl, sqlite3, mbstring, pcntl, phar, zlib) and you can verify them in CI. Recent releases also cover xlswriter, swoole, ICU, and krb5/PostgreSQL builds, so the long tail is broader than the headline list — verify your specific set rather than assuming.
• You can own release engineering: pinning versions (PHP, extension set, and native toolchain such as Zig and Clang), reproducible builds, checksums/signing, SBOM, and a rebuild cadence for PHP security releases.

Look elsewhere when:

• You need FPM/Apache/mod_php web serving, opcache-heavy workloads, or per-request isolation — use containers or a managed runtime.
• You depend on extensions that don't compile statically, or on proprietary extensions.
• Native Windows or exotic architectures are a hard requirement today. Windows work is active (2.8.5 fixed PostgreSQL library/header paths on Windows) but still treat it as experimental until you have proven artifacts yourself.
• You want a library to require into an application — this is a build tool, and the zero-dependents figure confirms nobody consumes it that way.
• Your team has no appetite for compile toolchains and binary supply-chain work, or you need vendor SLAs — this is a single-maintainer MIT project.
• Minimum mitigations if adopting: pin the release and the toolchain (Zig >= 0.16 as of 2.8.5), lock the extension list, build in a container, verify artifacts against target distros (glibc, musl, and distro variants such as Linux Mint), and set a mandatory rebuild window for PHP security patches and native-toolchain updates.

How to Pitch It (Stakeholders)

Executives: "Our CLI requires customers to install and maintain a matching PHP runtime — that's our top install-failure and support-ticket driver, and it disqualifies locked-down and air-gapped accounts. This lets us compile PHP and our code into one signed binary we ship like any other tool. Cost is a build pipeline; benefit is a removed support burden and access to a segment we currently can't serve. The project is actively maintained — the current patch release added extensions and fixed macOS and arm64 build issues — so the maintenance risk is toolchain drift rather than abandonment. Position it as cost avoidance and segment access; the project's low opportunity signal means we shouldn't forecast new revenue from it."

Engineering: "It's a build orchestrator: spc builds PHP with a curated static extension set and produces a self-contained binary; project bundling is supported too. Upside is one deterministic artifact instead of N distro matrices. Cost is that we own release engineering: pin PHP, the extension list, and the native toolchain (Zig >= 0.16, modern Clang — 2.8.5 dropped the pre-0.16 Zig workaround and fixed an aarch64 segfault under 0.16.0), build reproducibly, sign and checksum, publish an SBOM, rebuild on PHP security releases, and validate on glibc, musl, arm64, and macOS. It is not a web host — the serving tier stays on containers."

Decision requested: approve a 2–3 week spike — take one internal CLI, build for linux-x86_64 (glibc and musl), linux-aarch64, and macOS, then measure binary size, cold-start time, extension coverage, and CI build time before committing to ship-static vs. stay-container.