- How do I install lucasdotdev/laravel-soulbscription in a Laravel app?
- Run composer require lucasdotdev/laravel-soulbscription and pin it to ^4.3.2 so the 4.3.2 expiration fix cannot be rolled back by an older lockfile. Then publish the migrations and config, run the migrations, and apply the subscriber trait to your User or Team model. Finish by seeding a plan and feature catalog and registering the renewal command on the scheduler. The bulk of the effort is domain modeling rather than plumbing.
- Which Laravel and PHP versions does Soulbscription support?
- The package is evaluated here against Laravel 10 and 11 on PHP 8.1 or newer, backed by MySQL or Postgres and the standard Laravel scheduler. It is a conventional database-backed domain package and introduces no new infrastructure class. Always confirm the exact constraints in the package's composer.json for the 4.3.x line and check the maintainer's stated support window before committing.
- How do I define plans and features with Soulbscription?
- You build a plan and feature catalog as Eloquent records, then attach the subscriber trait to the model that owns access, such as User or Team. Subscriptions reference a plan, and features are attached to plans with quotas that get consumed by your application code. Because the subscriber model choice is hard to reverse later, decide between User and Team before you start.
- Does Soulbscription handle payments through Stripe or Paddle?
- No. Soulbscription is explicitly not a payments or billing-gateway package; it owns entitlement state, not money movement. If you use Stripe or Paddle you must decide which system is the source of truth for subscription status, and who reconciles when the two drift. Mirroring a provider's state means paying a recurring operational tax in reconciliation work.
- How does feature consumption and quota tracking work in Soulbscription?
- Feature consumptions are written as records on the hot path whenever a subscriber uses a metered feature, and remaining quota is derived from those records against the plan's limits. That design is clean but means consumption rows accumulate quickly in busy applications. Plan a pruning or archival policy from day one rather than retrofitting one later.
- Why should I pin Soulbscription to 4.3.2 instead of 4.3.0 or 4.3.1?
- 4.3.2 is a hotfix: it stops a preset expiration being stamped on plans with no periodicity during the renewal pass. That was a data-correctness bug, so installs on 4.3.1 or earlier may hold expires_at values that should not exist. Treat any upgrade as upgrade plus data audit: query subscriptions on non-periodic plans that carry a non-null expires_at and null them out once you have confirmed intent. The release is semver-compatible with no config or migration changes indicated.
- How do I register the Soulbscription renewal command on the Laravel scheduler?
- Add the package's renewal command to your Laravel scheduler and let it run through cron or a schedule:run worker, the same way you run other scheduled jobs. Also add monitoring and alerting on run success and on subscriptions that have lapsed unexpectedly. Without that visibility, a silent scheduler failure turns into wrongly granted or wrongly revoked access.
- Is the Soulbscription renewal command idempotent and safe under overlapping runs?
- There is no locking guarantee documented, so treat idempotency as an open question and confirm the behavior with the maintainer. In practice, guard the scheduled task with Laravel's withoutOverlapping and avoid running duplicate scheduler workers against the same table. Load-test the command in a sandbox before it touches production entitlements.
- Does Soulbscription handle upgrade, downgrade and proration logic?
- The package models plans, periodicity and grace periods, but it does not document coverage for upgrade, downgrade or proration semantics, so assume you own that logic. Spike two or three real commercial scenarios in a sandbox before committing to the design. Keep entitlement checks behind a feature flag so you can toggle back to existing access logic during cutover.
- Is Soulbscription actively maintained, and what are the risks of adopting it?
- It is a single-maintainer project with a narrow contributor base, so bus factor and long-term continuity are the main risks to weigh. The dependency itself is thin, but it needs active stewardship and a periodic review of release notes. If your commercial model is purely usage-metered or rating-based, or you want payments and entitlements from one vendor, evaluate alternatives before adopting.