[ ← blog / drupal ](/) Jun 13, 2023  ·  \#drupal  ·  2 min read 

# Registering services to the Drupal service container without a module 



Drupal's [service container for dependency injection](https://www.drupal.org/docs/drupal-apis/services-and-dependency-injection) allows modules to register services and parameters to the service container or alter and modify the service container. Usually, this is done with a [`services.yml`](https://www.drupal.org/docs/drupal-apis/services-and-dependency-injection/services-and-dependency-injection-in-drupal-8#s-defining-your-own-services) file provided by a module or a [service provider](https://www.drupal.org/docs/drupal-apis/services-and-dependency-injection/altering-existing-services-providing-dynamic-services) for dynamic registration and alteration. But! Did you know you can integrate with Drupal's service container without a module?

Most PHP applications provide a base kernel, and then the application code extends the kernel for registering services. Drupal doesn't follow this pattern as extension and development of Drupal typically happen through modules. It isn't obvious, but it is documented in the [`globals.api.php`](https://git.drupalcode.org/project/drupal/-/blob/11.x/core/globals.api.php#L45-55) file:

```php
/**
 * Allows defining of site-specific service providers for the Drupal kernel.
 *
 * To define a site-specific service provider class, use code like this:
 * @code
 * $GLOBALS['conf']['container_service_providers']['MyClassName'] = 'Drupal\My\Namespace\MyClassName';
 * @endcode
 *
 * @see \Drupal\Core\DrupalKernel::$serviceProviderClasses
 */
global $conf;
```

The global `$conf` variable can be used to define site-specific service providers! I have used this trick for some time to carry around various reusable code I like using on my for-fun projects without porting around modules. It is also how I made [Retrofit](https://mglaman.dev/blog/retrofit-running-legacy-drupal-7-code-your-drupal-10-site).

There are two places you can register the service provider:

- In your `sites/default/settings.php`
- In a file that Composer autoloads

I often prefer the latter option as it's more portable but may be more reasonable for other projects. Retrofit provides a [`bootstrap.php`](https://github.com/mglaman/retrofit-drupal/blob/main/bootstrap.php) file that Composer autoloads and configures its service provider.

```php
<?php

declare(strict_types=1);

use Retrofit\Drupal\Provider;

$GLOBALS['conf']['container_service_providers']['retrofit'] = Provider::class;
```

That service provider then hooks into Drupal to make Retrofit possible!

Why would I use this over a module? Most times, I wouldn't. But I always like to bend the ways we develop with Drupal.

 

  ![](/themes/custom/mglaman/images/headshot.webp)Thanks for reading

I write about Drupal, PHP, and the quiet infrastructure behind large sites — caching, config, and testing. New posts land every week or two.

 [Subscribe via RSS →](/rss.xml) [About me →](/about-me) 

 



 

  [← Older

Retrofit: Running legacy Drupal 7 code on your Drupal 10 site

 ](/blog/retrofit-running-legacy-drupal-7-code-your-drupal-10-site) [Newer →

Using jq with Drush to inspect state values in Drupal

 ](/blog/using-jq-drush-inspect-state-values-drupal)