n1crack / laravel-starter-kit
A Laravel starter kit serving public pages with Blade and Livewire, and the admin and user panels with Inertia and React.
Package info
github.com/n1crack/laravel-starter-kit
Language:TypeScript
Type:project
pkg:composer/n1crack/laravel-starter-kit
Requires
- php: ^8.4.0
- inertiajs/inertia-laravel: ^3.2.1
- laravel/fortify: ^1.37.3
- laravel/framework: ^13.23
- laravel/tinker: ^3.0.2
- laravel/wayfinder: ^0.1.20
- livewire/livewire: ^4.3
- nunomaduro/essentials: ^1.2.0
- spatie/laravel-permission: ^8.3
Requires (Dev)
- driftingly/rector-laravel: ^2.5.0
- fakerphp/faker: ^1.24.1
- larastan/larastan: ^3.10.0
- laravel/boost: ^2.4.13
- laravel/pail: ^1.2.7
- laravel/pint: ^1.30.1
- mockery/mockery: ^1.6.12
- nunomaduro/collision: ^8.9.5
- pestphp/pest: ^5.0.2
- pestphp/pest-plugin-browser: ^5.0.0
- pestphp/pest-plugin-laravel: ^5.0.1
- pestphp/pest-plugin-type-coverage: ^5.0.0
- rector/rector: ^2.5.9
- roave/security-advisories: dev-latest
This package is auto-updated.
Last update: 2026-08-06 19:06:12 UTC
README
A Laravel kit that asks what you are building and installs only that.
Requirements
PHP 8.4 · Node 22
Getting started
laravel new my-app --using=n1crack/laravel-starter-kit
cd my-app
composer dev
The install asks four things:
How should the public pages be rendered? Blade + Livewire / React (Inertia)
Would you like to add teams support? yes / no
Would you like to add multi-tenancy? yes / no
Which database will your application use? SQLite / MySQL / MariaDB / PostgreSQL / SQL Server
Answering yes to multi-tenancy asks two more: which domains serve the application itself, and what tenant database names should be prefixed with.
composer dev runs the server, queue worker, log viewer and Vite together.
To load demo data — an admin@example.com account plus 25 users, all with the password password:
php artisan db:seed
What's inside
- Laravel 13, Inertia 3, React 19, Tailwind 4
- Authentication via Fortify: registration, login, password reset, email verification, two-factor
- Roles via spatie/laravel-permission, with an
/adminarea behindrole:admin - Typed routes generated by Wayfinder
- Pest, PHPStan, Pint, Rector, oxlint and Prettier, wired into CI
The admin and user panels are always React. The public-page question only covers the public pages, so nothing in the kit has to exist twice.
Teams
Answering yes adds teams with membership roles (owner, administrator, member),
email invitations, member management, team deletion and a switcher in the
sidebar. Team roles live on the team_user pivot; the application-wide
admin and user roles stay with spatie and are unaffected.
Multi-tenancy
Answering yes installs stancl/tenancy and turns the kit into a tenant-facing application: one database per tenant, resolved from the request domain or subdomain.
Everything the kit ships becomes tenant-owned. Its migrations move under
database/migrations/tenant and its routes move into routes/tenant.php;
the central database is left holding only tenants and domains. There is no
central login — authentication happens on a tenant domain.
Run Composer once afterwards, since the package is only added when asked:
composer update
php artisan migrate # central: tenants and domains
php artisan tenants:create acme --seed
tenants:create makes the tenant, its database, and its first domain, then
migrates it. --seed adds the demo users; leave it off for a real tenant.
The tenant is then served at acme.your-central-domain.
After adding a migration under database/migrations/tenant, apply it to
tenants that already exist:
php artisan tenants:migrate
What is shared and what is not
| Where it lives | Why | |
|---|---|---|
| Users, sessions, roles, teams, your tables | Tenant | Nothing about them is shared |
| Cache | Tenant | Isolated by the connection, not by cache tags — the default database store cannot tag |
| Queue tables | Central | One queue:work serves every tenant; each job is restored to its own tenant |
| Tenants, domains | Central | The registry the request is resolved against |
The cache, session, rate limiter and auth guard are all rebuilt when tenancy
switches. Each is resolved once and then held, so without that a tenant would
read another's rows — and the rate limiter, which guards signing in, would
reach for a cache table the central database does not have.
Tenants themselves are expected to be administered by a separate application.
tenants:create exists so the kit can be run locally.
Layout
| Path | Contents |
|---|---|
routes/web.php |
Public pages and authenticated user settings |
routes/admin.php |
Admin area (auth, verified, role:admin) |
routes/tenant.php |
Tenancy only: wraps the above in tenant identification |
resources/views |
Blade pages and Livewire components |
resources/js/pages |
Inertia React pages |
stubs/ |
The optional features, published by the installer |
Commands
composer dev # server, queue, logs and Vite composer test # type coverage, unit tests, linting, static analysis composer lint # Rector, Pint and oxlint, applying fixes
The test suite enforces 100% code coverage and 100% type coverage.
Nothing under stubs/ is covered by those, because the linters only see a
working application. CI therefore installs every combination of answers into a
clean checkout and runs Pint, Rector, PHPStan, type coverage and the test
suite against the result.
License
MIT