- How do I install and set up Doorman in a Laravel application?
- Install it with composer require clarkeash/doorman, then publish the package config and migrations, run php artisan migrate, and register the middleware alias so it can be attached to routes. After that you attach the middleware to a route group and build a small redemption controller and form yourself, because the package ships the engine but no admin CRUD or UI. There are no external dependencies such as Redis, a queue, or an outside API, so setup is limited to Composer, config, migrations, and middleware registration.
- Which Laravel and PHP versions does Doorman support?
- Doorman targets the Laravel 9 through 12 era on PHP 8.x with a standard Composer install, so check the composer.json constraints for the exact version you are pinned to. Because it only adds middleware, a facade, and Eloquent-backed storage, it does not modify guards, providers, or session drivers, which keeps it stable across upgrades. Run your normal test suite after a Laravel major upgrade to confirm the middleware alias registration still matches the framework's current bootstrap style.
- How do I restrict Laravel registration to invite codes only with Doorman?
- This is the lighter-touch integration pattern: validate the submitted code with the Doorman facade inside your registration flow before the user record is created, then let Breeze, Jetstream, or Fortify handle the rest normally. It keeps the change small and reversible, and it avoids gating every request in the application. Remember to render clear error states for invalid, expired, and exhausted codes, and redirect to the intended page after a successful redemption.
- Can I limit how many times an invite code is used and set an expiry date?
- Yes, codes are generated through the Doorman facade with usage limits and expiry, and the middleware rejects codes that are exhausted or past their date. The important caveat is concurrency: a usage counter implies a read-modify-write operation, and concurrent redemptions can over-issue if the implementation does not use a transaction with row locking. Verify the behaviour under load and, if needed, wrap redemption in your own transactional boundary and add a database unique constraint as a backstop.
- Is Doorman compatible with Laravel Breeze, Jetstream, and Fortify?
- It coexists cleanly with all of them because Doorman is an access gate layered in front of routes or registration, not an authentication system. The correct mental model is invite-only allowlist rather than auth, so you sequence it alongside your starter kit rather than instead of it. Do not expect Doorman to replace guards, providers, or password handling.
- How do I protect routes with Doorman middleware instead of the whole application?
- Register the middleware alias and attach it to a route group containing only the pages you want behind a code, such as a private beta landing area or a registration route. Middleware placement is a silent-failure surface: any route registered outside the protected group is simply open, so cover your intended route list with an explicit automated test rather than relying on code review. Keep the protected group defined in one place so new routes are added inside it by default.
- Does Doorman work for API or token-based authentication?
- Not naturally, because Doorman gates access through session-based middleware and has no meaningful analogue for token-authenticated requests. An API deployment needs a custom redemption endpoint plus a persistence decision about whether the code binds to a user record or to token metadata. If stateless API access is on your roadmap in the next year, plan that custom layer now instead of retrofitting it later.
- How should I test that Doorman invite code middleware protects every route?
- Write feature tests that hit each protected route without a redeemed code and assert a redirect or 403, and repeat them with valid, invalid, expired, and exhausted codes. Then add a route-coverage test that inspects the registered routes and asserts the Doorman middleware is present on your intended list, since a missing middleware alias produces no error. Use RefreshDatabase and seed codes through the Doorman facade so the tests exercise the real generation path.
- Are Doorman invite codes secure, and should I hash them or add rate limiting?
- Treat codes as credentials: they are bearer tokens, they are plaintext at rest by default, and short alphanumeric codes are enumerable. Put the redemption endpoint behind Laravel's throttle middleware, review the configured code length and entropy instead of accepting defaults, and consider hashing codes at rest if they grant anything beyond a landing page. Also note there is no user binding by default, so sharing a code is the expected failure mode unless you add the user or organisation association yourself.
- Is Doorman still maintained, and what are the alternatives for invite-only registration?
- Doorman is a single-maintainer package with around a thousand stars and zero dependents, which is expected for an application-level package rather than an adoption signal, but there is no vendor SLA. Pin a version, keep the integration thin, and be prepared to fork if maintenance stalls. Many teams instead build a small invite codes table with their own redemption endpoint, optionally combined with Laravel's signed URLs and rate limiting, which gives full control over hashing, user binding, and audit logging.