Laravel Source Encrypter Laravel Package

Product Decisions This Supports

• Commercial delivery model: on-prem / self-hosted vs. SaaS-only. This package is the cheapest way to unblock a "ship our Laravel app to the customer's server" SKU without handing over readable source. That decision — do we sell a deployable artifact or only a hosted subscription — is often gated on exactly this capability, so this package lets you run the on-prem experiment for days of effort rather than a rewrite.
• Build vs. buy for IP protection. The realistic alternatives are ionCube, Zend Guard/SourceGuardian, or shipping containers/compiled artifacts. Those are commercial licenses with per-seat or per-server costs and encoder toolchain overhead; this is MIT, Composer-installed, and runs as an artisan command. Choosing it is a decision to buy obfuscation, not security — price it accordingly and don't promise more than that.
• Licensing and entitlement architecture. Because the runtime loader sits between the autoloader and your code, it's the natural chokepoint for domain/host binding, expiry checks, and per-install keys. If your roadmap includes tiered licensing, metering, or a kill-switch for lapsed contracts, this is where that hook lives.
• Distribution and release engineering. Encrypting a build implies a distinct "release build" pipeline separate from your dev build: what gets encrypted, what stays plain (config, views, vendor), what the customer can still customize. That's a product decision about configurability and support surface, not just a CI step.
• Support and SLA scoping. Encrypted artifacts make customer-side debugging materially harder and make "send us your stack trace with line numbers" worse. Adopting this package forces an explicit decision about what support you offer on self-hosted installs, and whether you ship a debug/unencrypted path under NDA.
• Competitive positioning and price ceiling. If a competitor ships readable source and you ship encrypted source, that's a sales objection you need an answer for. Conversely, encryption lets you charge for the product rather than the source, which usually raises the effective price ceiling.
• Roadmap signal on ecosystem maturity. 586 stars but zero dependents remains the key data point: real interest, still no production validation trail. Release 1.6.0 adds Laravel 11 & 12 support via an outside contributor — that removes a hard compatibility gate and shows the project is actively maintained, but it does not create a dependents signal. Net effect: the spike/PoC decision now has a lower technical risk and the same adoption risk. Keep the "revisit before GA" checkpoint, but the "will it even run on our stack" objection is largely retired.

When to Consider This Package

Consider it when most of the following hold:

• You are distributing a Laravel application to customer-controlled infrastructure and the primary threat is casual copying, resale, or a client handing your code to a cheaper contractor — not a determined reverse engineer.
• You need Laravel-native ergonomics: an artisan encrypt command, exclusion rules, and no proprietary encoder in CI. Your team should not need to learn a new toolchain.
• You are on a currently supported Laravel line — as of 1.6.0 that explicitly includes Laravel 11 and 12, so you can standardize on a modern framework version rather than pinning the product to an EOL release just to keep the encryptor working.
• You want MIT licensing and no per-server runtime fees, and you're willing to own the encryption key management and the loader's compatibility with your PHP/Laravel versions yourself.
• You need a fast PoC to validate demand for a self-hosted SKU before committing budget to a commercial encoder or a containerized delivery model.
• Your deployment target is a conventional VM or bare-metal host where you control OPcache settings, the PHP version, and file layout.

Look elsewhere — or don't encrypt at all — when:

• You need a credible security boundary. Any PHP-level self-decrypting loader must carry the key on the customer's disk. That's obfuscation. If the requirement is "a motivated attacker cannot recover the logic," that is a different product (ionCube/SourceGuardian) or a different architecture (SaaS, API-behind-the-firewall, or compiling hot paths to a native extension).
• The customer runs restricted or managed hosting (shared hosting, locked OPcache, disabled eval/stream wrappers, read-only filesystems). Compatibility failures here become support tickets you cannot fix. Note the 1.6.0 compatibility work targets framework versions, not exotic hosting environments — that risk is unchanged.
• Your product's value depends on customer code modifications or extensibility — encryption and "customize our PHP" are mutually exclusive.
• Vendor maturity risk is unacceptable. 1.6.0 is a real improvement — a second contributor landed framework support, which is the most common way single-maintainer packages die — but there are still zero dependents and no security-response track record. If your release cycle is contractually pinned to this working on the next Laravel major, assume you are the maintainer of last resort until the dependents count moves.
• You already have a clean SaaS or containerized delivery path. Encryption buys you little against a customer who already accepts a signed container image, and costs you debuggability.
• The real requirement is anti-tamper or license enforcement rather than anti-copying. A loader keyed to the same machine the attacker controls is not an enforcement mechanism; treat license checks as a compliance nudge, not a control.

How to Pitch It (Stakeholders)

To executives: We can open a self-hosted revenue line without exposing our source, using a free, MIT-licensed Laravel package that drops into our existing build. It's roughly a sprint of integration work and no licensing cost — versus five-figure annual encoder licenses or a multi-quarter replatform to containerized delivery. The latest release added support for the current Laravel versions, so we are not building this on an abandoned or version-locked library. Be clear on the trade: this raises the cost of copying our code; it does not make copying impossible. Sell it as a commercial deterrent with a licensing hook, not as a security guarantee, and we keep the option to upgrade to a hardened encoder if a deal requires it.

To engineering: It's an artisan command plus a runtime decryption layer in the autoload path. Benefits: no proprietary encoder in CI, MIT, works with our current Laravel conventions, gives us one obvious place to hang license/host checks, and as of 1.6.0 it officially supports Laravel 11 and 12 — so no framework downgrade to adopt it. Costs you must plan for: key management is ours, encrypted builds are effectively undebuggable in the field, OPcache and PHP-version behavior need explicit testing, and the ecosystem is still thin — 586 stars, zero dependents, one primary maintainer plus one drive-by contributor. So: adopt behind an interface, isolate it to the release pipeline, prove it across our supported PHP/Laravel matrix (11 and 12 are now on the table — test them, don't assume), and keep a build flag that ships plain source so we're never blocked by an upstream stall. This is a reversible decision if we architect it as one.