Every Laravel project has the same paragraph buried in its README. Open four terminal tabs. In tab one, run php artisan serve. In tab two, php artisan queue:work. In tab three, npm run dev. In tab four, php artisan pail. Some projects updated that paragraph to point at composer dev. Most did not.

What artisan dev actually does

php artisan dev, released June 17 in Laravel 13.16.0, replaces that paragraph. The command runs your dev server, queue worker, log tailing, and Vite concurrently from a single process. By default its behavior matches what composer dev already did. The difference is where the configuration lives.

Configuration moves out of composer.json

In a composer.json script you have a string. Maintaining it means editing JSON in a file that nobody reviews carefully, with no autocomplete, no type checking, no ability to vary by environment. With artisan dev, the dev process set is registered in a service provider through a DevCommands class:

use Illuminate\Foundation\Console\DevCommands;

DevCommands::artisan('reverb:start');
DevCommands::register('stripe listen --forward-to ' . config('app.url'));

That second line is the one that should catch your attention. Stripe webhook forwarding. Reverb. Inertia SSR. A Mailpit listener. A queue worker on a non-default connection. Every one of those is a per-project decision that historically lived in someone's head, a screenshot in Notion, or a stale README. Putting them in a versioned service provider means they get reviewed in pull requests, ship with the codebase, and travel with the project to the next developer.

What it solves for teams

If you're solo, the framework-level integration is mostly a typing savings. If you're on a team, it solves a different problem. Onboarding a new developer to a Laravel codebase has historically involved a setup README that was last accurate three releases ago, a Slack thread asking the senior dev which background processes they actually have running, and a half-day of "wait, I'm not seeing the queue jobs fire." Moving dev process configuration into application code closes that gap. Whatever runs on your machine runs on theirs, because the configuration is in app/Providers/AppServiceProvider.php, not in the wiki.

Each process can be color-coded for legibility:

DevCommands::artisan('reverb:start', 'reverb')->orange();
DevCommands::register('stripe listen --forward-to ' . config('app.url'))->green();

When php artisan dev runs, output streams are interleaved with prefixed, colored labels. After an hour of php artisan queue:work and stripe listen outputting unprefixed JSON into the same terminal, you understand why this matters.

The quieter change: vendor packages locked out

There is a quieter change in this release that deserves attention. The new DevCommands class explicitly prevents packages in the vendor directory from registering dev commands automatically. Only your own application code can call DevCommands::artisan(...) or DevCommands::register(...). A package can still ship a helper that you invoke from your own service provider, but it cannot quietly inject a background process into your dev environment via its own service provider.

This is a security and predictability win that the changelog buries. If you have ever run composer require something-totally-fine/package and discovered later that it was running a metrics collector or a license checker in the background of every developer's machine, you already understand the value. The framework is treating the dev process set as application configuration, not as an extension point for the package ecosystem. That choice matters more than the command itself.

Auto-detecting your package manager

The release also ships a NodePackageManager helper that detects npm, yarn, pnpm, or bun from the lockfiles present in the project. A generic command resolves to the right runner without per-project configuration. If half your repos are on pnpm and half are on npm, this matters. If you have ever pulled down a side project and watched it try to run npm run dev against a pnpm-lock.yaml, this matters more.

A wider pattern in Laravel

There is a wider pattern here. Composer scripts have been quietly hollowed out across Laravel's recent releases. Tooling that used to live as JSON strings keeps migrating into PHP service providers, where it can be typed, tested, and version-controlled. Application code is winning over configuration files for anything that involves logic. This is the same instinct behind our preference for multi-file Livewire components over the new single-file ones, and the same reason we picked the TALL stack over component-as-template hybrids in the first place. PHP is the configuration language. The fewer string-based escape hatches your project depends on, the more your team can refactor without fear.

Not a production replacement

This is not a Procfile replacement for production. artisan dev is explicitly for development, and the documentation is careful about that distinction. Your production process supervisor stays whatever it is: Supervisor, systemd, or your platform's worker config. If you are running on Laravel Cloud or Forge, nothing about this changes the deployment story. It changes only what happens between git clone and the first working request on a developer's laptop.

What to do this week

Two practical notes for teams already on Laravel 13. First, upgrade to 13.16.1, not 13.16.0. The point release contains a fix for a registration bug that Paul Redmond flagged in the announcement, with the original orchestration work in PR #60412. Second, move your existing composer dev script into a service provider this week. Add the cross-team niceties that have been living in someone's local setup: the Stripe listener, the Reverb starter, the queue worker on a specific connection. Commit it. Delete the four-terminal paragraph from your README.

This is the kind of framework-level decision that compounds. Every project we ship at Pixelworx starts with a custom Laravel build on the TALL stack, and every project inherits whatever onboarding friction was present in the framework when we picked it up. Moving the dev environment from convention into version control is exactly the kind of change that makes the next developer's first day shorter than the last one's. Worth the upgrade.