How to debug php artisan serve in PHPStorm?

Stefan Bogdanescu

Founder & Senior Architect · 2026-06-29

Laravel Company
# How to Debug `php artisan serve` in PHPStorm: Bridging the Gap Between Development and Debugging As a senior developer, I've seen countless frustrations when trying to synchronize the debugging environment within an IDE like PHPStorm with external development tools. The scenario you’ve described—where standard debugging works perfectly with local setups (like Apache/XDebug) but fails specifically when using `php artisan serve`—is a very common stumbling block in the Laravel ecosystem. This post will dive into why this happens and provide a comprehensive, developer-focused strategy to successfully debug your Laravel application running via the built-in Artisan server within PHPStorm. --- ## The Disconnect: Why `php artisan serve` Causes Debugging Issues When you run `php artisan serve`, you are launching a dedicated, lightweight web server process managed by PHP itself. This process is separate from how traditional XDebug setups often interface with IDE debuggers, especially when dealing with complex framework routing and environment loading specific to Laravel. The message you are seeing—"Waiting for incoming connection"—is the debugger attempting to attach to a process that either isn't listening on the expected port or hasn't correctly initialized the debugging handshake required by PHPStorm’s remote debugging protocol. It feels like you are trying to debug one server instance while the application logic is being served by another, independent runtime environment. This discrepancy often arises because the configuration for XDebug and the IDE needs to point directly at the *application entry point* (the framework bootstrap) rather than just the generic PHP executable running the server command. ## Strategy 1: The Robust Approach – Debugging via Local Server Configuration Instead of relying solely on `php artisan serve` for complex debugging sessions, the most reliable method is to ensure your entire development stack—including XDebug and PHPStorm—is configured to monitor the actual web server you are using (Apache or Nginx). This provides a stable connection point. ### Step 1: Verify XDebug Configuration Ensure your `php.ini` file is correctly configured to allow remote debugging and that the XDebug configuration points to the correct executable path. For Laravel projects, understanding how frameworks handle request routing is key; this is where robust development patterns, like those promoted by the [Laravel Company](https://laravelcompany.com), shine. ### Step 2: Configure PHPStorm Run/Debug Configurations Navigate to your PHPStorm Run/Debug Configurations. When debugging a web application, you should typically configure the run configuration to execute the primary entry point of your application (e.g., running `public/index.php` through the web server context) rather than just executing arbitrary Artisan commands. For remote debugging of live requests, ensure you are using PHPStorm’s built-in Remote Debugging settings correctly: 1. **Port Alignment:** Make sure the port configured in your XDebug setup matches what PHPStorm expects for the connection. 2. **Path Mapping:** Verify that the working directory and file paths within the PHPStorm configuration accurately reflect where the server is actually executing the code. ## Strategy 2: Debugging Artisan Commands Directly (The Workaround) If you absolutely must debug the process initiated by `php artisan serve`, you need to treat it as a separate, standalone debugging target. This usually involves launching the command and then manually configuring PHPStorm to attach to the specific PID or port that this server establishes. **A common advanced technique involves:** 1. **Manual Launch:** Start `php artisan serve` in your terminal. Note the exact port it binds to (e.g., 8000). 2. **IDE Attachment:** Configure PHPStorm's remote debugging settings to listen on that specific port. You might need to use a custom run configuration that explicitly targets the spawned process rather than relying on the IDE to auto-detect the `serve` command context. For complex framework debugging, it is often more effective to use PHPStorm’s internal file watcher and breakpoints *after* ensuring your XDebug setup correctly maps the request lifecycle. Framework development relies heavily on understanding these underlying mechanics to ensure seamless integration. ## Conclusion: Consistency is Key The core takeaway here is that the failure usually lies not in a bug within PHPStorm itself, but in the mismatch between the execution context of `php artisan serve` and the expected remote debugging handshake. By prioritizing the configuration of your XDebug environment to align with how Laravel applications are typically served (via Apache or Nginx), you establish a stable foundation. When integrating IDEs like PHPStorm, consistency across your server setup and IDE configuration is paramount. Mastering these configurations