- What is Laravel Soulbscription used for?
- Laravel Soulbscription is an entitlement layer for Laravel applications: you define plans and features, attach subscriptions to any Eloquent model, and control feature access plus consumable quotas through an expressive API. It ships with models for plans, features, subscriptions, and feature consumption, along with publishable migrations and a service provider that auto-discovers. It is not a payments or receipts system, so it is typically paired with a billing provider rather than replacing one.
- How do I install lucasdotvin/laravel-soulbscription?
- Install with composer require lucasdotvin/laravel-soulbscription, then publish and run the package migrations and add the provided trait to your subscriber model, usually User. After that you seed your plans and features and start gating access in policies or middleware. A working vertical slice can be in place in days, but decide your entitlement model first, meaning which features are consumable versus boolean and which plans are periodic versus lifetime.
- Which Laravel versions does laravel-soulbscription support?
- The package is Laravel-native, using service provider auto-discovery, Eloquent models, and publishable migrations and config, so it fits a standard Laravel app without extra infrastructure. Exact Laravel and PHP constraints live in the package composer.json, so check that file or the Packagist page against your app version before installing. It only structurally requires a relational database and a subscriber model, with no mandatory queue, cache, or external service.
- How do I attach a subscription to my User model?
- You apply the package trait to the model that should be billable, which is typically your User model, and that model becomes the subscriber for plan and feature checks. Subscriptions reference that model, so any Eloquent model can hold one rather than only users, which is useful for teams or organizations. Once the trait is in place you create subscriptions from your plan records and evaluate features against the subscriber.
- Can Laravel Soulbscription track consumable features and quotas?
- Yes, consumable features and quota tracking are core to the package, backed by a FeatureConsumption model that records usage against a subscription. You define which features are consumable when modeling your plans, then consume and check remaining quota through the package API, with renewals resetting or refreshing those quotas. Decide early which features are consumable and which are simple boolean flags, because that choice hardens into your schema and seed data.
- Does laravel-soulbscription handle payments, invoices, or Stripe?
- No, Laravel Soulbscription is an entitlement and feature management layer, not a payments layer, so it does not process charges, invoices, or receipts. You pair it with something like Stripe Billing, Chargebee, or Lago for money movement, and that system remains the source of truth for whether a subscription is paid. The reconciliation question, meaning how payment events map to subscription and plan changes in this package, is something you own and should design explicitly.
- What is the difference between periodic and non-periodic plans in laravel-soulbscription?
- Periodic plans have a billing period, so renewals move the subscription forward and stamp a new expiration. Non-periodic plans, such as lifetime, one-off, or contract plans, have no periodicity, and renewing them must not set an expiration date. Version 4.3.2 fixed a bug where renewals on plans with no periodicity were being given a preset expiration, so this interaction of null periodicity, renewal, and expiration is the area to test hardest in your own catalog.
- Is laravel-soulbscription safe to use in production given it has a single maintainer?
- It is a single-maintainer package with no commercial backer or second reviewer, which is a real bus-factor risk for a revenue-adjacent path. The mitigation is architectural: wrap it behind an internal interface such as an EntitlementService with can() style methods, pin it with ^4.3, and read the changelog on every bump. Teams with low tolerance for that risk should plan to fork or vendor the package, or at minimum keep entitlement logic thin and precomputed rather than spread across the request path.
- How do I upgrade from 4.3.1 to 4.3.2 and do I need to fix data?
- 4.3.2 is a patch release and a drop-in for 4.3.1 with no expected code changes on your side, so the dependency bump itself is simple. However, it corrects behavior rather than adding capability: subscriptions created or renewed on a non-periodic plan under 4.3.1 or earlier may carry a spurious expires_at. Audit those rows and clear the incorrect expiration as data remediation, ideally in a staging environment that replays real subscription data before you touch production.
- How does laravel-soulbscription compare to Stripe Billing, Chargebee, or Lago?
- Stripe Billing, Chargebee, and Lago are full billing platforms that handle payment collection, invoicing, dunning, and revenue reporting. Laravel Soulbscription solves a narrower problem: defining plans and features, attaching subscriptions to models, and gating access with consumable quotas inside your Laravel app. Most teams combine the two, using the hosted platform for money and this package for entitlements, and the main decision is which system owns subscription state and how the two stay reconciled.