Laravel Source Encrypter Laravel Package

Technical Evaluation

Architecture fit This is a build-time release toolchain, not a runtime library. It has two halves that must be reasoned about separately: an Artisan-driven encryption pass that runs in CI against a compiled Laravel application, and a companion native PHP extension (phpBolt) that must be compiled for and loaded on the target host to decrypt files at include time. That makes it a fit only for one architecture: shipping a Laravel codebase to infrastructure we do not control (on-premise appliance, white-label deployment, client-hosted instance, license-gated distribution). For a SaaS deployment where we operate the servers, it adds cost with no threat-model benefit, since anyone with shell access to our own hosts is already inside the trust boundary. It is explicitly not a runtime dependency and should be a require-dev entry, never shipped in the production lockfile of the distributed app.

Integration feasibility Composer install is trivial and the MIT license permits commercial redistribution without legal review. Release 1.6.0 (PR #43) adds Laravel 11 and 12 support, which widens the supported framework window but does not change the integration surface: the real work remains the extension, which must be built with phpize/gcc against the exact PHP minor version, matching ZTS/NTS setting, architecture, and ABI of the runtime, then registered via php.ini. This is feasible in a containerized delivery model where we control the base image; it is fragile-to-impossible in shared hosting or customer-managed VMs where we cannot install extensions or edit php.ini. Ecosystem signals remain thin: ~586 stars and a current release, but zero dependents — a meaningful absence of third-party validation at scale, meaning we should expect to be the ones discovering edge cases. The 1.6.0 support was contributed by a first-time contributor, so it is worth confirming whether Laravel 12 was validated end-to-end against the compiled extension or only against the package's Composer constraints. A one-to-two day spike against our actual Laravel version (9–12), PHP version, and deployment target should gate any further commitment.

Technical risk

• Hard coupling to PHP version. A PHP patch upgrade without a rebuilt extension produces a fatal load failure, not a degraded mode. Every PHP upgrade becomes a coordinated two-artifact release. Laravel 12 raises the floor to PHP 8.2, which pulls our extension build matrix forward to 8.2/8.3/8.4 and increases the rebuild cadence we must staff.
• Encryption strength. This is obfuscation, not cryptographic protection. The decryption capability ships with the extension, so a determined party can recover plaintext from memory or by tracing the include hook. Position it as a speed bump against casual copying and license circumvention, not as IP protection.
• Opaque artifacts. Encrypted files cannot be diffed, code-reviewed, or statically analyzed post-build, and stack traces lose fidelity. This directly degrades incident response and Sentry-class observability.
• Opcache interaction. Decryption cost is paid at compile time, so with opcache enabled the per-request overhead is acceptable; without it (or with a misconfigured opcache.validate_timestamps), you get both CPU cost and stale-code-after-deploy bugs.
• Reflection-dependent code. Packages or our own code doing runtime source inspection (class loaders, code generators, IDE helper generation) may break against encrypted files. Laravel 11/12 lean harder on attribute- and reflection-driven bootstrapping, so re-run this audit against the target framework version rather than assuming the prior result holds.
• Framework-coupling drift. The package's Laravel support window now advances independently of the extension; a framework bump is a lockfile change, but we must verify it does not silently alter the encryption pass output or artifact format.

Key questions

1. Which PHP versions, architectures, and ZTS/NTS combinations have prebuilt binaries — specifically 8.2/8.3/8.4 — and what is the upstream turnaround for new PHP releases?
2. Does our target deployment environment permit custom extensions and php.ini edits, or must we ship the container image ourselves?
3. Does it correctly handle Blade views, config/route caching, migrations, and vendor/ (encrypt or exclude), and has that been reverified on Laravel 11/12 rather than 10?
4. What is the key-management story — one global key baked into the extension, or per-customer keys with revocation?
5. Can we retain a plaintext build channel for support and symbolication without violating our own distribution policy?
6. Is the 1.5 → 1.6 upgrade a drop-in for already-encrypted artifacts, or does it require a full re-encrypt and customer reissue?
7. What is the upstream bus factor, and can we fork and maintain the C extension internally if the maintainer stops?

Integration Approach

Stack fit Appropriate for Laravel 9–12 / PHP 8.1+ (8.2+ on Laravel 12) distributed-application scenarios. Inappropriate for internal SaaS, for anything running on shared hosting, and for any app whose value depends on customers extending or debugging it in place.

Migration path Introduce it as an additive CI stage rather than a refactor: add --dev dependency, publish the config, define an explicit exclusion list (test suites, dev tooling, and any path that must remain inspectable), produce an encrypted artifact alongside — not instead of — the plaintext build. The plaintext build becomes an internal-only artifact retained for support. Bake the compiled extension into the delivery image or installer so customers never touch phpize. Treat the 1.6.0 bump as a lockfile-only change; if the pilot is already live on 1.5, re-encrypt and redeploy rather than mixing artifact versions across customers.

Compatibility Pin the build image and the runtime image to the same PHP major.minor, ZTS flag, architecture, and compiler ABI. Container parity is the only reliable way to guarantee this; document it as a hard constraint, not a guideline. Record the Laravel major alongside the PHP minor in the supported-matrix table now that 9 through 12 are in scope. Verify opcache is enabled and correctly configured in the shipped image, and audit our dependency tree for anything doing runtime source reflection before the first encrypted build.

Sequencing

1. Spike: encrypt and deploy a throwaway Laravel app end-to-end on the real target environment, on the framework version we actually intend to ship.
2. Build the CI job plus extension build/install automation; produce both artifact variants.
3. Pilot with one low-risk, cooperative external deployment.
4. Roll out per-customer with a documented installer and a supported Laravel/PHP matrix.
5. Establish a PHP-upgrade runbook that mandates extension rebuild and validation before any PHP bump.

Operational Impact

Maintenance Two coupled but separately versioned artifacts to track: the Composer package and the C extension. Every PHP patch release triggers extension rebuild and regression testing. Framework support now advances via community pull requests (1.6.0 arrived as a first-time contributor's PR), which is welcome but not a substitute for internal ownership — assume single-maintainer upstream risk and vendor the extension source internally so we can patch it ourselves, and pin the package version rather than floating on ^1.

Support Support engineers lose the ability to read deployed source or get accurate line numbers from stack traces. This raises MTTR and requires deliberate investment: map build hashes to retained plaintext source, maintain a mirrored plaintext staging environment for reproduction, and pre-write the "customer reports a bug in encrypted code" playbook. Budget for a noticeable support-quality dip in the first month.

Scaling Runtime overhead is modest and largely amortized by opcache. Horizontal scaling in containers is clean because the extension is baked into the image; scaling across heterogeneous customer-managed VMs is where the cost concentrates. The limiting factor is not performance — it is the size of the supported environment matrix, which grows with each Laravel/PHP combination we claim.

Failure modes All failures are hard, none graceful: extension not loaded → fatal error / blank page; PHP version mismatch → load failure or segfault; missing or mismatched encrypted file → fatal; stale opcache after redeploy → old code silently served; over-aggressive encryption of vendor/ → class-not-found; artifact encrypted by 1.5 loaded against a 1.6-generated runtime (or vice versa) → decryption failure on the affected files. Mitigate with a pre-flight check (php -m assertion plus a smoke endpoint) in the deployment health gate and an automated rollback path to the plaintext build.

Ramp-up Roughly 1–2 engineering days for the spike, 1–2 weeks to productionize the pipeline, installer, and docs. The 1.6.0 release does not materially change this estimate; the hidden cost remains customer-side environment variance, which is unbounded and should be constrained by shipping our own base image rather than supporting arbitrary hosts.