Modular feature packages with license-gated access via devso.me

[Devsome]

Motivation

Currently, the silkpanel‑cms codebase contains all features in a single monolithic application. We want to transition to a modular architecture where certain premium features are extracted into standalone Composer packages. Access to these features must be controlled by the license status obtained from devso.me.

Administrators using silkpanel‑cms will see all available features in the Filament navigation menu, but features not covered by their current license will be visually disabled (greyed out, not clickable). Only customers with a paid, active license (not trial) can activate and use the corresponding packages.

Proposed solution

1. License server integration (devso.me)

   • silkpanel‑cms already communicates with https://devso.me to validate the license key.
   • The license validation response will be extended to include information about which feature flags / packages are unlocked based on the customer’s plan (e.g., trial vs. paid, duration 1/3/12 months).
   • The CMS caches this entitlement information locally and refreshes it periodically (e.g., daily or on every license heartbeat).

2. Modular packages with private Composer repository

   • Premium features are developed in separate repositories and published as private Composer packages on https://composer.devso.me.
   • The custom Composer server verifies the license key before allowing package downloads (e.g., via a bearer token or basic auth derived from the license key).
   • During composer install or composer update, the CMS authenticates with the license key to fetch only the packages that the license entitles.

3. Filament navigation with disabled items

   • The CMS core provides a registration point for feature packages to add navigation items.
   • If a package is not installed (or its license is invalid/expired), the corresponding menu item is still shown in the Filament sidebar/top bar but rendered in a disabled state (greyed out, tooltip: “Upgrade your license to access this feature”).
   • The navigation configuration is dynamic and based on the locally cached entitlement list.

4. Feature package structure (guidelines)

   • Each package must have a service provider that registers its Filament resources, pages, and navigation items.
   • The service provider should check a global LicenseManager before enabling routes or UI elements (defensive check, in case the package is installed but license became invalid later).
   • Packages must not duplicate core logic; they extend the CMS via documented hooks and extension points.

5. Fallback behavior

   • If the license server is unreachable during a heartbeat, the last known valid entitlements are retained for a grace period (e.g., 7 days). After that, premium features become unavailable and their menu items disabled.
   • Core/free features remain unaffected regardless of license status.

Acceptance criteria

• The CMS can be extended by requiring additional silkpanel/* packages via Composer from composer.devso.me.
• License validation against devso.me returns detailed feature flags (e.g., fake-players, advanced-reports, …) based on the purchased plan.
• In the Filament admin panel, menu items for features that are not licensed are visible but disabled (greyed out) with an explanatory tooltip.
• If a paid license expires, previously active feature packages become inaccessible and their menu items revert to disabled.
• Trial licenses show all feature menu items disabled (or a subset, according to trial rules).
• The license check and package authentication add no noticeable performance overhead; entitlements are cached locally.
• Developers can build new feature packages independently, following a documented interface, and distribute them through the private Composer repository.
• The solution works on all environments supported by silkpanel‑cms (no hard dependency on specific PHP extensions beyond Composer’s requirements).

Out of scope

• Refactoring of existing premium features into packages (this ticket sets the foundation; actual migration of features is handled in separate tickets per package).
• Frontend display of disabled features for non‑admin users (this is purely the admin panel navigation).
• Automatic license upgrades or payment processing inside the CMS – all purchasing happens on devso.me.
• Package versioning strategy and CI/CD for composer.devso.me – that belongs to a separate infrastructure ticket.