> ## Documentation Index
> Fetch the complete documentation index at: https://kawax.biz/llms.txt
> Use this file to discover all available pages before exploring further.

# Request lifecycle

> Learn how HTTP requests and console commands are handled in a Laravel application.

## Introduction

When using a tool in the "real world," understanding how that tool works gives you more confidence in using it. The same is true of application development. When you understand how your development tools work, you can build applications more comfortably and confidently.

This page provides a high-level overview of how the Laravel framework works. By understanding the framework as a whole, everything stops feeling like "magic," and your confidence in building applications grows.

## HTTP request lifecycle

### The overall flow

```mermaid theme={null}
flowchart TD
    A[Browser/HTTP request] --> B[public/index.php]
    B --> C[Load Composer autoloader]
    C --> D[bootstrap/app.php]
    D --> E[Create application instance<br>Service container]
    E --> F[HTTP kernel]
    F --> G[Run bootstrappers<br>Error handling/logging/environment detection]
    G --> H[Register and boot service providers<br>register → boot]
    H --> I[Pass through middleware stack]
    I --> J[Routing]
    J --> K[Execute controller/closure]
    K --> L[Generate response]
    L --> I
    I --> M[Send response to browser]
```

### The first steps

The entry point for all requests to a Laravel application is the `public/index.php` file. All requests are forwarded to this file by your web server (Apache / Nginx) configuration. The `index.php` file itself contains very little code. It's a starting point for loading the rest of the framework.

The `index.php` file loads the Composer generated autoloader definition and then retrieves an instance of the Laravel application from `bootstrap/app.php`. The first action Laravel takes is to create an instance of the application / [service container](/en/service-container).

### HTTP kernel

Next, the incoming request is sent to the HTTP kernel (`Illuminate\Foundation\Http\Kernel`). The request is handled using the application instance's `handleRequest` method.

The HTTP kernel defines an array of **bootstrappers** that run before the request is executed. These bootstrappers perform the following:

* Configure error handling
* Configure logging
* [Detect the application environment](/en/installation)
* Other tasks that need to happen before the request is handled

The HTTP kernel is also responsible for passing the request through the application's middleware stack. These middleware handle reading and writing the [HTTP session](/en/session), determining whether the application is in maintenance mode, [verifying the CSRF token](/en/middleware), and more.

The signature of the HTTP kernel's `handle` method is simple: it receives a `Request` and returns a `Response`. Think of the kernel as a big black box that represents your entire application. Feed it HTTP requests and it will return HTTP responses.

### Service providers

One of the most important tasks during the kernel's bootstrapping is loading your application's [service providers](/en/service-providers). Service providers are responsible for bootstrapping all of the framework's various components, such as the database, queue, validation, and routing.

Laravel iterates through the list of providers and instantiates each one. After instantiation, the `register` method of every provider is called. Then, once all providers are registered, the `boot` method of each provider is called. This ensures that by the time a service provider's `boot` method is invoked, all container bindings are registered and available.

<Info>
  User-defined and third-party service providers are registered in the `bootstrap/providers.php` file.
</Info>

### Routing

Once the application has been bootstrapped and all service providers have been registered, the `Request` is handed off to the router for dispatching. The router dispatches the request to a route or controller, and also runs any route-specific middleware.

Middleware provide a convenient mechanism for filtering or examining HTTP requests entering your application. For example, Laravel includes middleware that checks whether the user is authenticated. If the user is not authenticated, the middleware redirects them to the login screen. If they are authenticated, the middleware allows the request to proceed further into the application.

Once the request has passed through all the middleware assigned to the matched route, the route or controller method is executed and a response is returned.

### Returning the response

Once the route or controller method returns a response, the response travels back outward through the route's middleware, giving the application a chance to modify or inspect the outgoing response.

Finally, once the response has passed back through the middleware, the HTTP kernel's `handle` method returns the response object to the application instance's `handleRequest` method, which calls the returned response's `send` method. The `send` method sends the response's content to the user's web browser. That completes the entire journey of a Laravel request lifecycle.

## Console command lifecycle

### The overall flow

```mermaid theme={null}
flowchart TD
    A[Run artisan command] --> B[artisan]
    B --> C[Load Composer autoloader]
    C --> D[bootstrap/app.php]
    D --> E[Create application instance<br>Service container]
    E --> F[Console kernel<br>handleCommand]
    F --> G[Register and boot service providers<br>register → boot]
    G --> H[Load commands<br>app/Console/Commands]
    H --> I[Execute command]
    I --> J[Return exit code]
```

### The artisan entry point

The entry point for console commands is the `artisan` file in the project root. As with HTTP requests, the Composer autoloader is loaded and a Laravel application instance is created.

Next, processing is handed off to the console kernel via the application instance's `handleCommand` method.

### Console kernel and command execution

The console kernel also loads service providers, just like the HTTP kernel. After all providers have been registered and booted, the commands in the `app/Console/Commands` directory are loaded and the specified command is executed.

```shell theme={null}
php artisan make:controller UserController
```

This command is processed as follows:

1. The `artisan` file loads the Composer autoloader
2. Creates the application instance from `bootstrap/app.php`
3. The console kernel loads service providers
4. Finds and executes the `make:controller` command
5. Returns an exit code

## Focus on service providers

Service providers are truly the key to bootstrapping a Laravel application. The application instance is created, the service providers are registered, and the request is handed to the bootstrapped application. That's it.

Having a solid grasp of how a Laravel application is built and bootstrapped via service providers is very valuable. Your application's user-defined service providers are stored in the `app/Providers` directory.

<Info>
  The default `AppServiceProvider` is mostly empty. This provider is a great place to add your application's own bootstrapping and service container bindings. For large applications, you may want to create multiple service providers, each with finer-grained bootstrapping for a specific service used by your application.
</Info>

### The difference between register and boot

Service providers have two primary methods.

| Method     | Timing                                                   | Purpose                                                   |
| ---------- | -------------------------------------------------------- | --------------------------------------------------------- |
| `register` | Called for all providers after they've been instantiated | Only register bindings with the service container         |
| `boot`     | Called after every provider's `register` has completed   | View composers, event listeners, and other initialization |

<Warning>
  Do not register event listeners, routes, or other functionality inside the `register` method. You may accidentally use services provided by service providers that have not yet been loaded.
</Warning>

## Next steps

<Card title="Service container" icon="box" href="/en/service-container">
  Understand how dependency injection and the service container work.
</Card>

<Card title="Service providers" icon="plug" href="/en/service-providers">
  Learn how to bootstrap your application with service providers.
</Card>


## Related topics

- [Laravel MCP](/en/mcp.md)
- [BlueskyManager and HasShortHand](/en/packages/laravel-bluesky/bluesky-manager.md)
- [Service providers](/en/service-providers.md)
- [Session lifecycle events](/en/packages/laravel-copilot-sdk/session-lifecycle-event.md)
- [⚡ Getting started with Livewire 4 — reactive UIs without JavaScript](/en/blog/livewire-introduction.md)