Service providers

Learn how to register and boot your application’s services using Laravel service providers.

What are service providers

Service providers are the central place where all Laravel application bootstrapping happens. Your own application, as well as all of Laravel’s core services, are bootstrapped via service providers.

By “bootstrapping” we mean registering things, including service container bindings, event listeners, middleware, and even routes. Service providers are the central place to configure your application.

Laravel uses dozens of service providers internally to bootstrap its core services, such as the mailer, queue, and cache. Many of these providers are “deferred” providers, meaning they are not loaded on every request, but only when the services they provide are actually needed.

All user-defined service providers are registered in the bootstrap/providers.php file.

If you’d like to learn more about how Laravel handles a request, see the request lifecycle documentation.

Writing a service provider

All service providers extend the Illuminate\Support\ServiceProvider class. Most service providers contain a register and a boot method.

To generate a new provider, use the make:provider Artisan command. Laravel will automatically register your new provider in bootstrap/providers.php.

php artisan make:provider RiakServiceProvider

The register method

Within the register method, you should only bind things into the service container. You should never attempt to register any event listeners, routes, or any other piece of functionality within the register method. You may accidentally use services provided by service providers that have not yet been loaded.

<?php

namespace App\Providers;

use App\Services\Riak\Connection;
use Illuminate\Contracts\Foundation\Application;
use Illuminate\Support\ServiceProvider;

class RiakServiceProvider extends ServiceProvider
{
    /**
     * Register application services.
     */
    public function register(): void
    {
        $this->app->singleton(Connection::class, function (Application $app) {
            return new Connection(config('riak'));
        });
    }
}

Within any of your service provider’s methods, you always have access to the service container via the $this->app property.

The bindings and singletons properties

If your service provider registers many simple bindings, you may wish to use the bindings and singletons properties instead of manually registering each binding. When the framework loads the provider, it will automatically check these properties and register their bindings.

<?php

namespace App\Providers;

use App\Contracts\DowntimeNotifier;
use App\Contracts\ServerProvider;
use App\Services\DigitalOceanServerProvider;
use App\Services\PingdomDowntimeNotifier;
use App\Services\ServerToolsProvider;
use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    /**
     * All of the container bindings that should be registered.
     *
     * @var array
     */
    public $bindings = [
        ServerProvider::class => DigitalOceanServerProvider::class,
    ];

    /**
     * All of the container singletons that should be registered.
     *
     * @var array
     */
    public $singletons = [
        DowntimeNotifier::class => PingdomDowntimeNotifier::class,
        ServerProvider::class => ServerToolsProvider::class,
    ];
}

The boot method

If you need to register a view composer within a service provider, do so within the boot method. This method is called after all other service providers have been registered, meaning you have access to all other services that have been registered by the framework.

<?php

namespace App\Providers;

use Illuminate\Support\Facades\View;
use Illuminate\Support\ServiceProvider;

class ComposerServiceProvider extends ServiceProvider
{
    /**
     * Bootstrap application services.
     */
    public function boot(): void
    {
        View::composer('view', function () {
            // ...
        });
    }
}

Do not confuse the roles of the register and boot methods. register is only for registering bindings; use boot for initializing services and other setup.

Boot method dependency injection

You may type-hint dependencies for your boot method as well. The service container will automatically inject any dependencies you need.

use Illuminate\Contracts\Routing\ResponseFactory;

/**
 * Bootstrap application services.
 */
public function boot(ResponseFactory $response): void
{
    $response->macro('serialized', function (mixed $value) {
        // ...
    });
}

Registering service providers

All service providers are registered in the bootstrap/providers.php file. This file returns an array that contains the class names of your application’s service providers.

<?php

return [
    App\Providers\AppServiceProvider::class,
];

In Laravel 13, service providers are registered in bootstrap/providers.php instead of the providers array in config/app.php. Using the make:provider command automatically adds them.

When you run the make:provider Artisan command, Laravel automatically adds the generated provider to the file. If you created your provider class manually, add the class to the array yourself.

<?php

return [
    App\Providers\AppServiceProvider::class,
    App\Providers\ComposerServiceProvider::class,
];

Creating a custom service provider

Let’s actually create a custom service provider.

1. Generate the provider

   Generate the service provider with an Artisan command.

   php artisan make:provider PaymentServiceProvider
   
2. Bind in the register method

   Add bindings to the generated provider’s register method.

   <?php
   
   namespace App\Providers;
   
   use App\Contracts\PaymentGateway;
   use App\Services\StripePaymentGateway;
   use Illuminate\Contracts\Foundation\Application;
   use Illuminate\Support\ServiceProvider;
   
   class PaymentServiceProvider extends ServiceProvider
   {
       /**
        * Register application services.
        */
       public function register(): void
       {
           $this->app->singleton(PaymentGateway::class, function (Application $app) {
               return new StripePaymentGateway(
                   config('services.stripe.secret')
               );
           });
       }
   
       /**
        * Bootstrap application services.
        */
       public function boot(): void
       {
           // Write boot-time logic here, if any
       }
   }
   
3. Register it in bootstrap/providers.php

   If you used make:provider, it is registered automatically. For manual providers, add it yourself.

   <?php
   
   return [
       App\Providers\AppServiceProvider::class,
       App\Providers\PaymentServiceProvider::class,
   ];
   

Deferred providers

If your provider is only registering bindings in the service container, you may choose to defer its registration until one of the registered bindings is actually needed. Deferring the loading of such a provider improves the performance of your application, since it is not loaded from the filesystem on every request.

To create a deferred provider, implement the \Illuminate\Contracts\Support\DeferrableProvider interface and define a provides method. The provides method should return the service container bindings registered by the provider.

<?php

namespace App\Providers;

use App\Services\Riak\Connection;
use Illuminate\Contracts\Foundation\Application;
use Illuminate\Contracts\Support\DeferrableProvider;
use Illuminate\Support\ServiceProvider;

class RiakServiceProvider extends ServiceProvider implements DeferrableProvider
{
    /**
     * Register application services.
     */
    public function register(): void
    {
        $this->app->singleton(Connection::class, function (Application $app) {
                return new Connection(config('riak'));
            });
    }

    /**
     * Get the services provided by the provider.
     *
     * @return array<int, string>
     */
    public function provides(): array
    {
        return [Connection::class];
    }
}

Deferred providers are ideal for services that are only used by specific features rather than the entire application. Avoiding loading unnecessary services optimizes performance.

Next steps

Service container

Review the details of the service container and its bindings.