Laravel Service Providers Explained for New Developers

January 14, 2024 · 7 min read

Laravel for Beginners: Using Service Providers

2026 UPDATE - LARAVEL 13

We’re excited to announce that we have updated all of our blog post examples to reflect the new Laravel 13 version! Our previous examples were based on Laravel 10, but with the release of Laravel 13, we wanted to ensure that our readers have access to the most up-to-date information and examples.

What are Laravel Service Providers?

Think of Laravel Service Providers like the clothes you wear every day. Just as clothes are essential and you put them on to be ready for the day, Service Providers are essential for your Laravel application. They "dress" your app by setting it up and providing the necessary services it needs to run smoothly.

However, just as you don’t carry your food, tools, or other items with you all day, instead, you use them as needed, Laravel Service Providers are responsible for setting up and providing services that your application needs almost at all times. Other services or dependencies that your app needs only in specific situations can be resolved on demand, much like how you eat food or use tools when the time calls for it.

Service providers in Laravel are special classes where you can register and boot services, such as database connections, mail services, and custom logic. They tell Laravel how to glue different parts of your application together. Each provider can both register and configure services, making them ready for use across your app.

Understanding the Service Provider

A service provider extends the ServiceProvider class and contains two primary methods: register and boot.

The Register Method

The register method is used to bind services into the Laravel service container. This is where you can define how services are created, using simple or complex logic.

namespace App\Providers;

use Illuminate\Support\ServiceProvider;
use Illuminate\Database\Connection;

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

    /**
     * Bootstrap any application services.
     */
    public function boot(): void
    {
        //
    }
}

The Boot Method

The boot method is where you can interact with services that have been registered by the framework or other service providers. It’s a place to add additional functionality, like event listeners or middleware, or even to modify services that have already been registered.

namespace App\Providers;

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

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

    /**
     * Bootstrap any application services.
     */
    public function boot(): void
    {
        View::share('latestPosts', Post::latest()->take(5)->get());
    }
}

Creating Your Own Service Provider

For your blog, you might want to create a service provider to encapsulate specific functionality, such as a custom logging service or a content management feature.

To create a new service provider, use the command:

php artisan make:provider BlogServiceProvider

This command will create a new BlogServiceProvider in the app/Providers directory.

Registering a Service Provider

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

// This file is automatically generated by Laravel...
 
return [
    App\Providers\AppServiceProvider::class,
    App\Providers\BlogServiceProvider::class, 
];

Using Service Providers

Let’s say you want to create a set of custom helper functions for your blog, or you want to define a global variable that’s accessible in all views. You can do this within a service provider.

For instance, you might want to share the top five latest posts with all views so that you can display them in a sidebar on every page:

namespace App\Providers;

use Illuminate\Support\ServiceProvider;

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

    /**
     * Bootstrap any application services.
     */
    public function boot(): void
    {
        view()->composer('*', function ($view) {
			$view->with('latestPosts', Post::latest()->take(5)->get());
		});
    }
}

By placing this code in the boot method of your service provider, you’re instructing Laravel to make the $latestPosts variable available to all views, which can then be easily displayed in your blog’s sidebar.

Service Providers in Laravel 13 vs Older Versions

If you have worked with Laravel 9 or 10, you may remember several dedicated provider files in the app/Providers directory: RouteServiceProvider.php, AuthServiceProvider.php, EventServiceProvider.php, and BroadcastServiceProvider.php. Starting with Laravel 11 and continuing in Laravel 13, these files are gone.

Here is what replaced them:

RouteServiceProvider is gone. Routes are loaded automatically from routes/web.php and routes/api.php (the API routes file is no longer scaffolded by default, but you can run php artisan install:api to add it). Custom route loading goes in bootstrap/app.php.
AuthServiceProvider is gone. Define Gate policies and model-policy mappings inside AppServiceProvider::boot().
EventServiceProvider is gone. Register event listeners in AppServiceProvider::boot() or use the automatic event discovery feature.
Middleware is no longer registered in app/Http/Kernel.php (also gone). It is registered in bootstrap/app.php using the ->withMiddleware() method.

In practice, when you create a new Laravel 13 project, you will mainly work with AppServiceProvider for custom bindings, view composers, model observers, and boot-time configuration. For everything else, bootstrap/app.php is the entry point.

// bootstrap/app.php — Laravel 13 application bootstrap
return Application::configure(basePath: dirname(__DIR__))
    ->withRouting(
        web: __DIR__.'/../routes/web.php',
        commands: __DIR__.'/../routes/console.php',
        health: '/up',
    )
    ->withMiddleware(function (Middleware $middleware) {
        // Register global middleware, aliases, and groups here
    })
    ->withExceptions(function (Exceptions $exceptions) {
        // Customize exception handling here
    })->create();

Deferred Service Providers

By default, every registered service provider is loaded on every request, even if its bindings are not used. For providers that only register bindings in the container (no boot-time side effects), you can mark them as deferred. Laravel will only load a deferred provider when one of its registered services is actually resolved.

To defer a provider, implement the DeferrableProvider interface and add a provides() method that lists the bindings it registers:

namespace App\Providers;

use Illuminate\Contracts\Support\DeferrableProvider;
use Illuminate\Support\ServiceProvider;
use App\Services\ReportGenerator;

class ReportServiceProvider extends ServiceProvider implements DeferrableProvider
{
    public function register(): void
    {
        $this->app->singleton(ReportGenerator::class, function ($app) {
            return new ReportGenerator(config('reports'));
        });
    }

    /**
     * Return the services provided by this provider.
     */
    public function provides(): array
    {
        return [ReportGenerator::class];
    }
}

Deferred providers are a good fit for resource-intensive services (report generators, third-party API clients, large data processors) that are only needed on certain routes.

Frequently Asked Questions

What is a service provider in Laravel?

A service provider is a class that bootstraps and configures a part of your Laravel application. It has two methods: register() for binding services into the container, and boot() for actions that need to run after all services have been registered (such as sharing view data or defining event listeners). All providers are loaded early in the request lifecycle, making them the right place for application-wide setup.

When do I need to create a custom service provider?

Create a custom service provider when you need to bind interfaces to concrete implementations, register shared view data, integrate a third-party package that requires bootstrapping, or encapsulate initialization logic that does not belong in a controller. For most small-to-medium Laravel apps, AppServiceProvider is enough and you rarely need to create an additional provider.

What is the difference between register() and boot()?

The register() method runs before all providers have been booted, so you should only bind things into the service container here, never try to use another service inside register(). The boot() method runs after all providers have been registered, so every service is available and you can safely call other services, share view data, register event listeners, or define model observers.

What happened to RouteServiceProvider in Laravel 11+?

RouteServiceProvider was removed in Laravel 11. Route loading is now handled automatically by the framework based on the configuration in bootstrap/app.php. The HOME constant and any custom route prefix or domain logic that lived in RouteServiceProvider should now be placed in bootstrap/app.php inside the ->withRouting() closure. Similarly, AuthServiceProvider, EventServiceProvider, and BroadcastServiceProvider have been removed. Their responsibilities moved to AppServiceProvider or bootstrap/app.php.

Conclusion

Service providers are a fundamental part of the Laravel framework, giving you control over how services are registered and booted in your application. They are incredibly powerful for managing dependencies and organizing the way your app works under the hood.