Laravel Modules Licensing Laravel Package

Technical Evaluation

Architecture fit. ozankurt/laravel-modules-licensing is a Laravel service-provider package that layers licensing onto a modular monolith: a licensing server, Ed25519 offline key verification, a Core-free client SDK, HTTP endpoints, and optional Filament admin resources. v2.0.0 does not change that shape — it is a platform-generation release, not a feature release. The package's architectural value (offline verification means no per-request call to a licence server) is unchanged, which keeps the runtime topology flat.

Integration feasibility. Feasibility is now entirely gated by the host environment, not by application code. v2.0.0 hard-requires PHP ^8.4 with ext-sodium, Laravel ^13.0, and ozankurt/laravel-modules-core ^2.0. Any host still on Laravel 12 / PHP 8.3 cannot install it at all. Where the host is already on Laravel 13, integration is a composer require — the release notes explicitly state no public API changed and the suite passes on Laravel 13 with zero source changes.

Technical risk. Code risk is low; environment risk is high.

• Low: no API surface change, no deprecations in the package itself, identical endpoints and Filament resources, full suite green across Filament 3/4/5.
• High: the spatie/laravel-package-tools ^1.93 floor is a hard cliff — 1.92.x caps at Laravel 12, so any other installed package pinning ^1.92 (or an older Laravel constraint) will make the dependency solver fail. The ext-sodium requirement is usually satisfied by default builds but is a genuine risk in slim/alpine container images and some managed PHP runtimes.
• Unverified: the notes claim Filament 3, 4 and 5 on Laravel 13. Filament 3 is an older major; whether its Laravel 13 support is first-class or incidental should be confirmed rather than assumed.

Key questions.

1. Is the host application on Laravel 13 and PHP 8.4 today, or is this release the trigger for that migration?
2. Is ext-sodium present in every runtime (local, CI, staging, prod, any queue/worker images)?
3. Which Filament major is in production use, and is that combination CI-verified for us and not just for the maintainer?
4. Does laravel-modules-core ^2.0 have the same Laravel 13-only constraint, meaning the whole module suite must move in lockstep?
5. Will v1.1.0 continue to receive security fixes for teams staying on Laravel 12, and for how long?
6. Is the licensing server self-hosted (our uptime problem) or vendor-hosted (vendor dependency)?
7. Does the vendor's Laravel 13 support track Laravel's own support window (security fixes, LTS expectations)?

Integration Approach

Stack fit. Narrow but clean: PHP 8.4 + Laravel 13 + core ^2.0 + optionally one Filament major. On a Laravel 12 / PHP 8.3 stack this is not a package upgrade — it is a mandatory platform migration wearing a composer require. Treat it accordingly in planning and estimation.

Migration path. Because there is no public API change, no application code is expected to change. The migration is environmental and dependency-graph-shaped:

1. Inventory every dependency's Laravel and spatie/laravel-package-tools constraints; anything pinned below ^1.93 or to Laravel ≤12 is a blocker that must be upgraded first.
2. Confirm/ext install ext-sodium across all images and CI runners.
3. Move the host to Laravel 13 / PHP 8.4 in staging.
4. Move ozankurt/laravel-modules-core to ^2.0.
5. composer require ozankurt/laravel-modules-licensing:^2.0.
6. Leave Filament pinned to the major already in use; only widen if you are deliberately upgrading Filament.

Compatibility. Backwards compatible at the API level, forwards incompatible at the platform level. The practical constraint is that the entire dependency set must become Laravel 13-ready simultaneously — partial upgrades will produce solver conflicts rather than runtime errors, which is the safer failure but a slower one to unwind.

Sequencing. Do the platform upgrade and the core ^2.0 bump as one change before touching this package, so any failure is attributable. Keep v1.1.0 pinned on a maintenance branch if you need to ship fixes to a Laravel 12 deployment in parallel. Gate the production cutover on an explicit smoke test of the offline Ed25519 verification path (issue a key, verify offline, confirm expiry/invalid-key handling) — that is the one behaviour where a silent environment difference would be costly.

Operational Impact

Maintenance. A second supported train now exists: v1.1.0 for Laravel 12 / PHP 8.3, v2.0.0 for Laravel 13 / PHP 8.4. Dual-train maintenance is fine only if v1.1.0 still receives fixes; if it is effectively frozen, every consumer is on a forced-migration clock. The test toolchain moved to Pest 5 / Testbench 11 / PHPUnit 13, which matters if we upstream patches or run the package's own suite in our CI.

Support. Single-maintainer, small-ecosystem package. The absence of API churn is the mitigating factor — support surface is genuinely small — but there is no commercial backing to escalate to. Licensing logic is also a business-critical path (a bug here can lock users out of paid modules), so pinning exact versions and avoiding floating constraints is advisable.

Scaling. Runtime cost is negligible: Ed25519 offline verification is local CPU work and does not add network hops to request handling. Scaling concerns sit with the licensing server component if we host it (availability and throughput become ours) and with the Filament admin resources, which are ordinary admin-panel load. Neither is a throughput bottleneck at typical module-licensing volumes.

Failure modes.

• Missing ext-sodium → hard failure at boot/class-load, not a graceful degradation.
• Dependency conflict on laravel-package-tools or Laravel constraint → install blocked (loud, safe, but can stall a release train).
• Core ^2.0 mismatch → service-provider boot errors, likely at application startup.
• Filament major mismatch → resource registration errors in the admin panel only; licensing itself unaffected.
• Licensing server unreachable → online issuance/refresh fails; already-issued offline keys keep verifying, which limits blast radius. Confirm the offline-key TTL matches real-world outage tolerance.

Ramp-up. Low for application developers — no API change means no new mental model and no code rewrite. Moderate for platform/DevOps, who own PHP 8.4, the sodium extension in base images, CI matrix changes, and the Laravel 13 upgrade itself. For the TPM the real work is coordination: mapping the dependency graph for Laravel 13 readiness, sequencing the core package and this one together, and deciding whether a Laravel 12 maintenance branch is needed before the migration lands.