Laravel's Bootstrap Process

What Happens Inside Laravel

In the previous lesson, we followed a request from the browser to PHP-FPM. Now we're inside Laravel. PHP-FPM has loaded public/index.php, and Laravel's bootstrap process begins. Understanding this process demystifies the framework and helps you debug issues that seem inexplicable.

The Entry Point: public/index.php

Every Laravel request starts here. The file is deceptively short — about 20 lines. It does three things:

1. Loads Composer's autoloader — require __DIR__.'/../vendor/autoload.php'. This is how PHP knows where to find every class in your application and all your dependencies.
2. Creates the application instance — $app = require_once __DIR__.'/../bootstrap/app.php'. This builds the Service Container, Laravel's central orchestration object.
3. Handles the request — Creates an HTTP kernel, passes the incoming request through it, sends the response, and terminates.

The Service Container

The Service Container (also called the IoC Container) is the most important concept in Laravel's architecture. It's a registry that knows how to build objects and resolve their dependencies.

When you type-hint a class in a controller method:

public function store(Request $request, UserService $userService)
{
    // $request and $userService are automatically created for you
}

The container sees that store() needs a Request and a UserService, builds them (recursively resolving their dependencies too), and injects them. This is dependency injection, and it's happening everywhere in Laravel.

The container is also where you bind interfaces to implementations:

// In a Service Provider
$this->app->bind(PaymentGateway::class, StripeGateway::class);

Now any class that type-hints PaymentGateway automatically gets a StripeGateway. Want to switch to Braintree? Change one line in the binding.

Service Providers: The Bootstrap Registry

Service Providers are classes that register bindings with the container and perform bootstrap logic. Every Laravel feature — routing, database, authentication, queues — is bootstrapped by a service provider.

Look at config/app.php (or in Laravel 11+, bootstrap/providers.php). You'll see a list of providers that run on every request. Each provider has two methods:

• register() — Bind things into the container. No dependencies on other services should be used here.
• boot() — Called after all providers are registered. Now you can use any service. This is where you define route model bindings, event listeners, validation rules, etc.

Your AppServiceProvider is your main service provider. When you need to register something application-wide (like a rate limiter or a custom Blade directive), this is where it goes.

The Middleware Pipeline

After the application boots, the HTTP request passes through a middleware pipeline. Middleware are layers that wrap around your request, like an onion.

Laravel's default global middleware includes:

• EncryptCookies — Encrypts and decrypts cookie values.
• StartSession — Initializes the session (reads the session cookie, loads session data from storage).
• VerifyCsrfToken — Checks POST/PUT/DELETE requests for a valid CSRF token (this is why you get 419 errors when it's missing).
• ShareErrorsFromSession — Makes validation errors available to your views via $errors.

The request passes through each middleware's handle() method on the way in. After the controller returns a response, the response passes back through each middleware on the way out (in reverse order). This is how middleware can modify both requests and responses.

The Router and Controllers

The router matches the request's HTTP method and URL path against your defined routes. When a match is found:

1. Route-specific middleware runs (like auth, throttle, etc.).
2. If route model binding is configured (e.g., {user} in the URL), Laravel queries the database for the model.
3. The controller method executes, with dependencies injected by the container.
4. The controller returns a response (a View, JSON, redirect, etc.).

The Complete Lifecycle

1. public/index.php loads the autoloader and creates the application.
2. Service providers register() their bindings.
3. Service providers boot() with all services available.
4. The request enters the global middleware pipeline.
5. The router matches a route and runs route middleware.
6. Route model binding resolves URL parameters to Eloquent models.
7. The controller method executes with injected dependencies.
8. The response travels back through middleware (reverse order).
9. The response is sent to PHP-FPM, which sends it to Nginx, which sends it to the client.
10. Laravel terminates (runs terminable middleware, logs, etc.).

When something goes wrong in Laravel, knowing where in this lifecycle the failure occurs tells you exactly where to look. A 419 error? That's the CSRF middleware (step 4). A "target class does not exist" error? That's the container failing to resolve a binding (step 2). A ModelNotFoundException? That's route model binding (step 6).

Key Takeaways

• The Service Container builds objects and resolves dependencies automatically via type-hints.
• Service Providers register bindings and run bootstrap logic. They're the glue of the framework.
• The middleware pipeline wraps every request. Understanding the default middleware explains sessions, CSRF protection, and error handling.
• Knowing the lifecycle helps you debug faster — you can pinpoint which stage caused an error.