Laravel Modules Licensing Laravel Package

Product Decisions This Supports

• Monetization model for a module ecosystem. This package is the paywall plumbing: license issuance, Ed25519 offline key verification, HTTP endpoints, and a client SDK. It supports the decision to sell proprietary modules/add-ons rather than give them away or ship everything closed-source.
• Build vs. buy on licensing infrastructure. Choosing this package is a decision not to build a license server, key-signing pipeline, activation/validation endpoints, and an admin console in-house. Scope saved is a small internal service plus its ongoing maintenance.
• Offline / self-hosted enforcement. Ed25519 offline verification means customers on air-gapped or on-prem deployments can validate licenses without a phone-home. This unlocks a self-hosted or regulated-customer segment that a call-back-only design would exclude.
• Partner and third-party distribution. The "Core-free client SDK" lets licensing be embedded in modules that don't otherwise depend on laravel-modules-core. That widens the addressable module catalog beyond first-party code — a packaging and go-to-market decision, not just a technical one.
• Day-2 operations tooling. The optional Filament 3/4/5 admin resources cover issue/revoke/inspect workflows. This removes a bespoke back-office from the roadmap and sets the expectation that revocation is an operational, human-driven process.
• Supported-platform matrix (new in v2.0.0). Dropping Laravel 12 and PHP 8.3 makes Laravel 13 / PHP 8.4 / laravel-modules-core ^2.0 a hard gate for the licensing layer. That is a roadmap commitment with a customer-facing release consequence: any module release that depends on licensing v2 cannot ship to customers still on Laravel 12.

When to Consider This Package

Adopt when:

• You sell (or plan to sell) modules or add-ons in a Laravel module ecosystem and want licensing as infrastructure rather than a bespoke build.
• You need offline-capable enforcement — self-hosted, air-gapped, or locked-down customer environments where a license-server callback isn't viable.
• You are already on, or can schedule, Laravel 13 / PHP 8.4 with ext-sodium; v2 has no maintenance path for Laravel 12 / PHP 8.3, so staying put means freezing at v1.1.0.
• You are on the ozankurt/laravel-modules-core stack, or you specifically need a client SDK that does not require it.
• You already run Filament 3/4/5 and want the admin surfaces without extra build work.

Look elsewhere when:

• You need subscription billing with seats, usage metering, invoicing, or payment-provider integration. This is license-key verification, not a billing or entitlement-billing system.
• You want a vendor-operated, hosted licensing service. This hands you the server and the operational responsibility for it.
• You cannot move off PHP 8.3 / Laravel 12 in the planning horizon — there is no supported v1.1.0-to-v2 path without the host upgrade.
• You cannot accept the transitive ozankurt/laravel-modules-core ^2.0 requirement, or you have strict dependency-review constraints.
• You need DRM-grade or tamper-resistant protection. Ed25519 offline keys are a licensing gate with best-effort revocation, not obfuscation; plan key rotation into the terms.

How to Pitch It (Stakeholders)

Executives. This is the paywall for a module business, and v2.0.0 is a platform-baseline decision rather than a feature release. It adds no new surface area — the public API, licensing server, Ed25519 offline verification, Core-free client SDK, HTTP endpoints, and Filament resources are identical to v1.1.0 and the full suite passes on Laravel 13 with no source change. What v2 does change is requirements: PHP 8.4 and Laravel 13 become mandatory, dropping Laravel 12 and PHP 8.3. The decision to make is scheduling: move the host application forward and stay on the supported track, or freeze licensing at v1.1.0 and accept that we are off it. Migration cost is ours, not the vendor's, and it gates any future module release that depends on licensing. Two standing risks to note: running the licensing server is our operational responsibility, and offline keys make revocation best-effort, so key rotation belongs in the product terms.

Engineering. Requirements-only bump: PHP ^8.4 with ext-sodium, Laravel ^13.0, ozankurt/laravel-modules-core ^2.0, and optional Filament 3/4/5 for the admin resources. No public API changed — the licensing server, offline key verification, client SDK, HTTP endpoints, and Filament resources are the same as v1.1.0 and the suite is green on Laravel 13 without a single source change. The toolchain moved to Pest 5 / Testbench 11 / PHPUnit 13 and spatie/laravel-package-tools to ^1.93 (1.92.x caps at Laravel 12), so CI config and any copied test scaffolding need the same bump; CI now runs PHP 8.4 / Laravel 13.* / Testbench 11.* across Filament 3, 4, and 5. Upgrade path: move the host app to Laravel 13 / PHP 8.4 and core ^2.0, then composer require ozankurt/laravel-modules-licensing:^2.0.