Laravel Make User Laravel Package

Getting Started

Install the package with Composer; the service provider is auto-discovered, so no manual registration is required in modern Laravel:

composer require dyrynda/laravel-make-user

Check your version matrix first. As of the 8.2.0 release the package requires PHP 8.2+ and supports Laravel 11.x and 12.x. Laravel 10 and PHP 8.1 are no longer supported, so older apps must pin to the 8.1.x line:

# Laravel 11 / 12, PHP 8.2+
composer require dyrynda/laravel-make-user:^8.2

# Laravel 10 / PHP 8.1 (frozen)
composer require dyrynda/laravel-make-user:~8.1.0

Confirm what Composer actually resolved and verify the command is available and inspect its exact signature/options for your installed version:

composer show dyrynda/laravel-make-user
php artisan list | grep make:user
php artisan make:user --help

Run it interactively:

php artisan make:user

You will be prompted for the user's name, email address, and password (entered via a secret prompt with confirmation). On success the command persists the user through your application's configured user model.

Where to look first:

1. config/auth.php → providers.users.model — this is the model the command should resolve. If your app uses a non-default model or namespace, confirm it matches.
2. app/Models/User.php (or app/User.php on older apps) — check $fillable, casts, and any MustVerifyEmail implementation.
3. The package README and php artisan make:user --help — confirm which options (if any) your version exposes for non-interactive use.
4. The package source in vendor/dyrynda/laravel-make-user/src — useful because the package moves slowly and its documentation can lag behind Laravel changes.

First use case: bootstrapping an admin account on a freshly deployed application without exposing a registration route, opening php artisan tinker, or writing a one-off seeder. It is also handy locally for creating predictable test users.

Implementation Patterns

Interactive provisioning (local/staging). The primary workflow is simply running php artisan make:user in a terminal. Use this for the first admin user after php artisan migrate, or when manually reproducing a customer account.

Deployment / container entrypoint. After migrations complete, run the command in a one-off shell in the running container:

docker compose exec app php artisan make:user

Avoid baking it into an automated entrypoint unless you can supply credentials non-interactively.

Scripted creation. If your installed version exposes input options, pass them directly:

php artisan make:user --name="Admin" --email="[email protected]" --password="$ADMIN_PASSWORD"

If options are not available, the command is still usable from a seeder or test by driving the prompts. In tests:

$this->artisan('make:user')
    ->expectsQuestion('Name', 'Admin User')
    ->expectsQuestion('Email', '[email protected]')
    ->expectsQuestion('Password', 'secret-password')
    ->expectsQuestion('Password confirmation', 'secret-password')
    ->assertExitCode(0);

$this->assertDatabaseHas('users', ['email' => '[email protected]']);

In a seeder or deploy script, wrap Artisan::call() only if you have confirmed option support; otherwise create the user through the model directly and reserve the command for humans.

Post-creation hooks. The command creates a normal Eloquent model, so User::created observers fire. Use this to assign a default role (e.g., with spatie/laravel-permission), send a welcome notification, or set email_verified_at:

// app/Providers/EventServiceProvider.php or a model observer
User::created(function (User $user) {
    $user->assignRole('admin'); // only if you can distinguish bootstrap users
});

Beware: this fires for every creation path, so scope it carefully or use a dedicated make:admin command instead.

Extending the command. For repeatable, team-specific workflows, subclass the package command or register your own Artisan command that reuses the same prompts and adds role assignment, tenant ID, or verification. This is usually cleaner than forking the package.

Pairing with role/permission packages. The command only creates the user row. Any roles, teams, or profile records must be attached separately — typically in the same deploy step or via a model observer.

Upgrade path when going to Laravel 12. The 8.2.0 release is a compatibility bump, not a feature release: no new options, prompts, or behaviour changes. Upgrading is normally just a constraint change, but run your make:user test (prompt-driven or option-driven) once after the bump, since the underlying laravel/prompts and console input handling on Laravel 12 differ from 10.

Gotchas and Tips

Version floor and ceiling. 8.2.0 drops Laravel 10 and PHP 8.1. If your app is still on Laravel 10 or PHP 8.1, Composer will keep you on 8.1.x — do not force the upgrade; either raise your platform requirement first or stay pinned. Conversely, on Laravel 12 you must be on 8.2.0+, since 8.1.x declares no Laravel 12 support.

Maintenance cadence. The package is low-activity but has not been abandoned — 8.2.0 landed to add Laravel 12 support. It is still small and single-maintainer, so pin the major version in composer.json and treat any future Laravel major as needing a compatibility check (or a local reimplementation) rather than assuming it will keep up.

Model resolution. Confirm the command resolves the model from config('auth.providers.users.model'). The default moved from App\User to App\Models\User in Laravel 8, and older package versions may hardcode a namespace. If creation fails with a "class not found" error, this is the first thing to check. You can also point auth.providers.users.model at a subclass if needed.

Mass assignment. If your User model uses $fillable and does not include name, email, or password, creation will throw a MassAssignmentException (or silently drop fields, depending on implementation). Ensure the fields are fillable.

Password hashing. The command hashes the password before saving. If your model also declares a hashed cast, confirm you are not double-hashing. Check the stored hash with Hash::check() after creation if login fails.

Email verification. Newly created users typically have a NULL email_verified_at. If your app requires verified email to log in, set it explicitly:

$user->forceFill(['email_verified_at' => now()])->save();

Unique email constraint. The command may not validate uniqueness itself. If the email already exists, expect a QueryException from the database unique index. Check with User::where('email', ...)->exists() before invoking it in scripts.

Secrets in shell history. Passing --password= on the command line leaks into shell history, process listings, and CI logs. Prefer the interactive secret prompt, environment variables read inside a custom command, or a secrets manager.

CI and --no-interaction. In non-interactive environments, missing required inputs cause the command to fail or hang. Always test deploy scripts with --no-interaction and explicit inputs.

Config caching. If you publish or override package config, run php artisan config:clear / config:cache after changes. A cached config can mask model or connection changes — particularly relevant right after a Laravel 10 → 12 upgrade where auth.php may have been reshaped.

Debugging. Run with -vvv for stack traces, and check storage/logs/laravel.log. If the command appears to succeed but no row exists, verify the database connection and that you are not inside a transaction that was rolled back.

Production safety. Consider gating the command behind an environment check or a custom confirmation prompt. On shared production systems, unrestricted user creation is a privilege-escalation vector.

Extension point. The cleanest long-term path, if you need more than the command offers, is to write your own make:user command using laravel/prompts, resolve the model from auth.providers.users.model, hash with the hashed cast or Hash::make(), and add the role/verification logic your team actually needs. That removes the third-party dependency while preserving the day-to-day workflow.