Weave Code
Laravel Invite Only Laravel Package
offload-project/laravel-invite-only
A Laravel package for invite-only registration. Restrict signups to invited users, generate and manage invitation codes or email invitations, and control access with configurable middleware, models, and notifications. Ideal for private apps and beta launches.
A Laravel package for managing user invitations with polymorphic relationships, token-based access, scheduled reminders, and event-driven notifications.
Frequently asked questions about Laravel Invite Only
- How do I install and set up laravel-invite-only in a Laravel app?
- Install it with composer require offload-project/laravel-invite-only, then optionally run vendor:publish to export the config, language files, and migrations. Laravel package discovery registers the service provider automatically, so no manual provider entry is needed. Run php artisan migrate to create the invitation tables, then apply the package middleware to the registration routes you want to gate.
- Which Laravel and PHP versions does offload-project/laravel-invite-only support?
- The package follows standard Laravel package conventions and targets conventional Blade-based applications, but you should confirm the exact Laravel and PHP constraint in the composer.json of the specific release you install. The 2.x line is the current line, so check the repository's releases and issue tracker for its security-fix status before committing to it long term.
- How do invitation tokens work, and do they expire?
- Invitations are persisted as models with a token that gates access, and the package supports both invitation codes and email invitations. Expiry is configurable, so you decide how long a token remains valid before redemption is rejected. Token generation and expiry logic were unchanged in 2.6.0, so review those paths yourself as part of any security assessment.
- Can I customize the invitation email templates?
- Yes. v2.6.0 extends the publishable asset surface so invitation email templates can be exported into your application, not just translation files. Run vendor:publish with the new email tag to copy the Blade views into your app, then edit them to match your branding. This removes the most common reason teams forked the package just to change invitation markup.
- Is v2.6.0 a breaking change from v2.5.0?
- No. The release is additive and backwards compatible, so raising your Composer constraint to ^2.6 and running composer update is the whole upgrade. Installs that never publish views keep using the package defaults unchanged, and no database migration changes are implied. The main migration task is deleting any forked or hacked email views and switching to the supported published-view override.
- Are invitation emails queued, and is there rate limiting on invites?
- The release notes do not state whether invitation mail is queued by default, so inspect the mailable or notification class before relying on it for high-volume sends. Rate limiting on invite issuance and redemption is also not evidenced, so add throttling middleware to your issuance and acceptance routes if abuse is a concern. Both points are worth confirming during your integration review.
- What happens to published email views after a package upgrade?
- Once exported, those Blade views become application-owned code, and upstream template fixes or view-data contract changes will not reach your app automatically. Re-diff the published files against the package originals on each release and record the delta in your repository. Add the published view paths to your upgrade checklist so the templates do not silently drift and break during a send.
- How do scheduled invitation reminders work?
- The package supports scheduled reminders, so pending invitations can be nudged without a manual follow-up process. You still need a scheduler running via Laravel's schedule:run cron entry for those reminders to fire. Check the published config for the reminder cadence and any related options after installation.
- What are the polymorphic relationships on invitations used for?
- Invitations use polymorphic relationships, which lets an invitation be attached to whichever models represent the inviter, the invitee, or the resource being shared. That avoids adding package-specific columns to your own tables when you need to track who sent an invite and what it grants. Review the package migrations and model contracts to see the exact morph types it expects in your app.
- How should I test the invite lifecycle before going to production?
- Upgrade in a development branch, confirm composer update resolves and the service provider boots, then exercise the full flow: issue, deliver, accept, and expire. Send a real invitation through a staging mail transport rather than the log driver, and render it in the major email clients your users actually use. Only promote to production once rendering and acceptance both behave correctly.
Weaver
How can I help you explore Laravel packages today?