- How do I install sbamtr/laravel-source-encrypter in a Laravel app?
- Install it with Composer as a development dependency, typically with composer require --dev sbamtr/laravel-source-encrypter, since it is a build-time release toolchain rather than a runtime library. The package registers Artisan commands that you run against a compiled Laravel application in your CI or release pipeline. You also need the companion phpBolt native extension built and loaded on the target host for decryption at include time. Keep it out of the production lockfile of the distributed app.
- Which Laravel and PHP versions does this source encrypter support?
- It is aimed at Laravel 9 through 11 on PHP 8.x for distributed-application scenarios, and it also works with Lumen. Because the runtime half is a native extension, the practical constraint is your exact PHP minor version, architecture, and ZTS/NTS setting rather than the Laravel version alone. A short spike against your actual Laravel, PHP, and deployment target is the safest way to confirm compatibility before committing.
- Why should it be a require-dev dependency instead of a runtime package?
- The encryption side only runs at build or release time via Artisan, so there is no reason to ship it inside the application you distribute. The decryption side is provided by the phpBolt PHP extension installed on the target host, not by Composer autoloading. Keeping it in require-dev keeps the delivered codebase smaller and avoids leaking tooling details to the customer.
- Do I need to compile a PHP extension to use this package?
- Yes. The phpBolt extension must be built with phpize and gcc against the exact PHP minor version, matching architecture and ZTS/NTS configuration, then registered through php.ini. This is workable in a containerized delivery model where you control the base image, but it becomes fragile or impossible on shared hosting or customer-managed VMs where you cannot install extensions or edit php.ini. A PHP patch upgrade without a rebuilt extension causes a fatal load failure rather than a degraded mode.
- Can I use this package on shared hosting or a customer-managed server?
- Generally no. If you cannot install a custom PHP extension or edit php.ini on the target host, the loader cannot decrypt your files and the encrypted application will not run. It fits architectures where you ship the container image yourself, such as an on-premise appliance, white-label deployment, or a client-hosted instance under your control. For customer-managed VMs, plan on delivering the full runtime image rather than just the code.
- Is the encryption actually secure enough to protect my intellectual property?
- Treat it as obfuscation rather than cryptographic protection. The decryption capability ships with the extension, so a determined party can recover plaintext from memory or by tracing the include hook. It is a speed bump against casual copying and license circumvention, not a defense against a motivated reverse engineer. Position it accordingly in your contracts and product documentation.
- How does opcache affect performance of encrypted files?
- Decryption cost is paid at compile time, so with opcache enabled the per-request overhead is acceptable. Without opcache, or with a misconfigured opcache.validate_timestamps, you pay both the CPU cost and can hit stale-code-after-deploy bugs. Validate your opcache settings as part of the deployment checklist before going live.
- How should I handle Blade views, config and route caching, migrations, and the vendor directory?
- You need to decide explicitly what gets encrypted and what is excluded, and vendor/ is usually excluded so Composer packages keep functioning normally. Blade views, config cache, and route cache should be generated as part of the build before encryption so cached artifacts are valid in the shipped app. Verify each of these paths during your initial one-to-two day spike, since encrypted files cannot be inspected or diffed after the build.
- Will encryption break packages that use reflection or runtime source inspection?
- It can. Code that performs runtime source inspection, such as class loaders, code generators, or IDE helper generation, may break against encrypted files because the plaintext source is no longer visible. You also lose stack-trace fidelity, which degrades incident response and error tracking services like Sentry. Test your dependency set for reflection-heavy packages before rolling this out to customers.
- How is the encryption key managed, and what is the maintenance risk?
- Key management depends on how you configure phpBolt: you either bake a single global key into the extension or issue per-customer keys with a revocation plan, so decide which model your licensing requires before shipping. On maintenance, the project has roughly 586 stars and a recent 2025 release, but zero dependents, which means limited third-party validation at scale and a real bus-factor question. Plan for the possibility of forking and maintaining the C extension internally if upstream stalls.