- Is francescomalatesta/laravel-api-boilerplate-jwt a Composer package I can require into an existing Laravel app?
- No. It is a project scaffold that you adopt with composer create-project or by forking the repository, not a runtime dependency you add with composer require. Once adopted you own the entire application skeleton, and there is no upstream SemVer upgrade path or service provider to register. For a brownfield app, build the auth slice on Laravel Sanctum or Passport instead.
- How do I install laravel-api-boilerplate-jwt and get it running?
- Create a new project from the boilerplate rather than requiring it into an existing app. Configure your .env for the database and JWT signing secret, run migrations, and start the app on a PHP 7.x runtime that matches the Laravel 5.8 baseline. Containerizing the PHP version early keeps the scaffold bootable while you evaluate it.
- Which Laravel and PHP versions does this API boilerplate support?
- The boilerplate targets the Laravel 5.8 era and PHP 7.x, with pinned JWT dependencies from that period. It is not a PHP 8.2 or Laravel 10 package out of the box, so validate composer.json constraints against your target stack before committing. Treat that compatibility check as a go/no-go gate, not a minor detail.
- What authentication features are included out of the box?
- It ships a JWT-based auth flow with registration, login, token refresh, and logout, plus CORS handling and a PHPUnit test suite. That makes it a ready-to-use REST API foundation for first-party SPA or mobile clients using email and password. It is not a delegated OAuth2, SSO, or multi-tenant identity solution.
- Does the boilerplate handle JWT refresh, revocation, and blacklisting?
- Token refresh is part of the included flow, but you must confirm the exact refresh-token rotation and revocation strategy in the code before production. Check blacklist support, algorithm allow-listing, audience and issuer validation, and signing-key rotation against your compliance needs. A security review of the token lifecycle should be a release blocker.
- Can I use this boilerplate in a new Laravel 10 or PHP 8.2 project?
- Not without significant modernization. The baseline is Laravel 5.x and PHP 7.x with older tymon/jwt-auth and firebase/php-jwt constraints, and upgrading the skeleton can cost more than writing the auth slice fresh. If you need current Laravel, use Sanctum or Passport on a modern laravel/laravel skeleton.
- How do I run the PHPUnit tests included in the boilerplate?
- The repository includes a full PHPUnit test suite, so run it with vendor/bin/phpunit after installing dependencies. Configure a separate test database in phpunit.xml or your testing environment, run migrations, and execute the suite before changing auth behavior. Use the tests as a baseline, then add coverage for any token lifecycle changes you make.
- What are the best alternatives to this JWT boilerplate for a Laravel API?
- Laravel Sanctum is the first-party choice for first-party SPA and mobile token auth, while Passport fits only when OAuth2 is a real requirement. You can also read this repo as a reference for login, registration, refresh, logout, exception handling, and route structure, then implement on a current Laravel skeleton. That reference-only path keeps you on supported dependencies.
- Is laravel-api-boilerplate-jwt maintained and safe for production?
- Treat it as high risk: the project is a Laravel 5-era scaffold with no clear upstream security patch path, and JWT dependencies are a sensitive CVE surface. The zero-dependents and legacy star count signal past interest, not current maintenance. If you fork it, assign ownership, pin dependencies, generate an SBOM, and define a patch SLA before production.
- What use cases does this boilerplate fit, and what should I avoid?
- It fits a greenfield, single-tenant Laravel REST API for first-party clients that needs email/password auth, JWT issuance, refresh, logout, and CORS quickly. Avoid it for brownfield integration, delegated OAuth2, SSO, multi-tenant identity, or service-to-service auth. Keep auth behind a thin AuthService or TokenIssuer interface so you can swap the implementation later.