Static Php Cli Laravel Package

Technical Evaluation

crazywhalecc/static-php-cli (spc) is not a Composer-importable Laravel package in the conventional sense — it is a PHP-based build orchestrator that compiles fully static PHP binaries (with a curated set of ~80+ extensions) and can bundle application source via micro.sfx into a single executable. Treat it as infrastructure tooling, not a runtime dependency.

Release 2.8.5 delta (reviewed): a maintenance patch with no breaking changes, no deprecations, and no config schema changes. It is additive and corrective: two new extensions (decimal, deepclone), a Windows fix for PostgreSQL library/header path copying, a macOS build fix for xlswriter under modern Clang (C23), a Linux Mint variant mapping, and — the operationally interesting part — removal of the zig < 0.16 workaround plus a fix for an aarch64 shared-extension segfault under zig 0.16.0, alongside libkrb5/decimal build repairs. Net read for a TPM: low upgrade risk, mild positive on extension coverage, and fresh evidence that the cross-compile toolchain (zig) is a moving part that must be pinned.

• Architecture fit: Weak for the typical Laravel web request path (FPM/Octane/Nginx) and strong for adjacent use cases: shipping Laravel console applications, queue workers, or internal CLI tooling as self-contained binaries; air-gapped or appliance-style deployments; and — most relevantly — as the transitive build dependency behind FrankenPHP, which Laravel Octane supports. The Dependents: 0 metric is misleading: consumption happens via phar/binary in CI, not composer require, so the real user base (FrankenPHP, php-cs-fixer, PHPStan, Psalm distribution builds) is invisible to that counter. 2.8.5 does not change this positioning; decimal (arbitrary-precision decimals) is a genuine addition for financial/ledger-style CLI jobs that previously needed bcmath gymnastics, and deepclone is niche.
• Integration feasibility: High if the target is CLI distribution. Install is a phar or global Composer install; builds run in Docker or CI against a YAML/JSON config specifying PHP version, SAPI (cli, micro, fpm, embed), and extensions. Determinism improved markedly with lockfile support in recent v2.x releases, and 2.8.5's zig-version work is a reminder to pin the toolchain, not just the PHP version. The friction remains toolchain prerequisites (autoconf, bison, re2c, cmake, pkg-config, musl-cross-make or a pinned zig) and build duration — tens of minutes per target, CPU-heavy.
• Technical risk: (1) Supply chain — sources and patches are pulled from php.net, GitHub, and mirrors; checksums are enforced but the pipeline itself is a trust boundary your SBOM process must absorb. (2) CVE remediation requires a rebuild-and-redistribute loop; static linking removes the "patch libssl in the base image" escape hatch. (3) PHP release cadence — support for a new PHP minor typically lags weeks; extension coverage (swoole, imagick, grpc) trails further. (4) Platform asymmetry — Linux x86_64/aarch64 (glibc and musl) is first-class; macOS is supported; Windows is via Cygwin/WSL, not native — 2.8.5 improves Windows PostgreSQL and macOS/Clang paths but does not change that tiering. (5) Cross-compiler churn — the 2.8.5 aarch64 segfault under zig 0.16.0 is exactly the class of defect that appears on one architecture only; treat zig/musl versions as pinned, tested artifacts.
• Key questions: Which Laravel workloads genuinely require single-binary distribution versus a container image? Does the team already run Octane with FrankenPHP (in which case spc is already in the dependency graph)? Which extensions are non-negotiable (e.g., pdo_mysql, intl, redis, swoole, and now possibly decimal)? Is reproducible build + SBOM attestation a compliance requirement, and does it extend to pinning the C toolchain? Who owns the build pipeline and its CI minutes? What is the acceptable lag between a PHP security release and a rebuilt artifact? Are you building for aarch64 as well as x86_64 (which doubles the toolchain risk surface)?

Integration Approach

• Stack fit: Laravel 10/11/12 on PHP 8.1+ aligns with the PHP versions spc currently compiles (8.0–8.5). It slots in as a CI job, not an application service provider; no autoload, no config publishing, no migrations. Upgrading 2.8.4 → 2.8.5 is a pin bump; nothing in the release changes invocation or config shape.
• Migration path: Non-invasive by default. Standard FPM shops need no migration. Teams wanting Octane+FrankenPHP adoption get spc transitively and should evaluate FrankenPHP directly rather than spc in isolation. Teams wanting binary CLI distribution add a single CI stage: spc fetch → build with a pinned extension set and pinned toolchain → sign artifact → publish. 2.8.5 does not force a pipeline redesign; it does force a review of the pinned zig version in your build image if you had retained the < 0.16 workaround path.
• Compatibility: Extension matrix is the compatibility surface. Validate against your actual composer.json platform requirements and Laravel's own extension needs (mbstring, openssl, pdo_*, tokenizer, ctype, json, fileinfo, bcmath, curl). The new decimal extension is opt-in and additive — adding it widens the binary slightly, so only include it if a workload requires it. Note behavioral differences under musl (DNS resolution, locale handling) versus glibc — test in the target environment, not just locally, and test on aarch64 explicitly given the 2.8.5 shared-extension fix history.
• Sequencing: 1) Inventory console commands and CLI tools that would benefit from single-binary distribution. 2) Freeze a minimal extension set and pin the spc version + lockfile. 3) Stand up a dedicated Docker build image in CI with pinned zig/musl toolchain versions. 4) Add artifact signing and checksum publication. 5) Evaluate micro.sfx bundling only after the base pipeline is stable. 6) Revisit FrankenPHP/Octane as a separate, later workstream. Rolling to 2.8.5 is a low-ceremony step 2 activity: bump the pin, rebuild, run the binary smoke suite on both architectures.

Operational Impact

• Maintenance: Ongoing obligations are PHP version tracking, extension compatibility re-validation, upstream patch review, and rebuild cadence tied to OpenSSL/PHP security advisories. 2.8.5 is representative of the steady-state cost: a stream of small correctness fixes across platforms and toolchains that must be triaged and absorbed rather than ignored. Realistically a part-time owner plus CI budget; higher if you distribute artifacts externally.
• Support: Community-maintained under MIT with a small core contributor base and no commercial SLA. GitHub issues are the support channel. 2.8.5 shows healthy contributor throughput (one first-time contributor, several third-party fixes) but also that fixes often land in the same release as the regressions they address — acceptable for internal tooling, riskier for customer-facing distribution without an internal fallback plan.
• Scaling: Builds scale horizontally in CI but are CPU- and I/O-bound; cache PHP source tarballs and toolchain downloads aggressively. Multi-architecture targets (x86_64 + aarch64) roughly double build cost and are where 2.8.5's defects surfaced. Artifact size (tens of MB per binary, larger with micro.sfx) constrains distribution channels — CDN and download UX need planning. Runtime scaling is unaffected since the artifact runs as a normal process.
• Failure modes: Upstream source checksum drift or mirror unavailability; patch application failures on PHP point releases; extension compile regressions after an upstream bump (2.8.5 fixed exactly these for decimal and libkrb5); toolchain-version regressions such as the aarch64 zig 0.16.0 segfault; musl/glibc behavioral divergence surfacing only in production; oversized artifacts rejected by distribution infrastructure; silent staleness where a deployed binary embeds an outdated OpenSSL. Mitigations: pinned versions (PHP, spc, and C toolchain), scheduled rebuilds, automated smoke tests of the produced binary against your Laravel test suite on every target architecture, and artifact provenance metadata.
• Ramp-up: Low for PHP developers using the CLI, moderate-to-high for owning the build pipeline — autoconf/musl/zig toolchain knowledge is a distinct skill set. Budget roughly one day for a first successful build and one to two weeks for a hardened, signed, monitored pipeline; add a few hours for a multi-arch (aarch64) bring-up.