content/manuals/compose/how-tos/provider-services.md
{{< summary-bar feature_name="Compose provider services" >}}
Docker Compose supports provider services, which allow integration with services whose lifecycles are managed by third-party components rather than by Compose itself.
This feature enables you to define and utilize platform-specific services without the need for manual setup or direct lifecycle management.
Provider services are a special type of service in Compose that represents platform capabilities rather than containers. They allow you to declare dependencies on specific platform features that your application needs.
When you define a provider service in your Compose file, Compose works with the platform to provision and configure the requested capability, making it available to your application services.
To use a provider service in your Compose file, you need to:
provider attributetype of provider you want to useHere's a basic example:
services:
database:
provider:
type: awesomecloud
options:
type: mysql
foo: bar
app:
image: myapp
depends_on:
- database
Notice the dedicated provider attribute in the database service.
This attribute specifies that the service is managed by a provider and lets you define options specific to that provider type.
The depends_on attribute in the app service specifies that it depends on the database service.
This means that the database service will be started before the app service, allowing the provider information
to be injected into the app service.
During the docker compose up command execution, Compose identifies services relying on providers and works with them to provision
the requested capabilities. The provider then populates Compose model with information about how to access the provisioned resource.
This information is passed to services that declare a dependency on the provider service, typically through environment variables. The naming convention for these variables is:
<<PROVIDER_SERVICE_NAME>>_<<VARIABLE_NAME>>
For example, if your provider service is named database, your application service might receive environment variables like:
DATABASE_URL with the URL to access the provisioned resourceDATABASE_TOKEN with an authentication tokenYour application can then use these environment variables to interact with the provisioned resource.
The type field in a provider service references the name of either:
docker-model)When Compose encounters a provider service, it looks for a plugin or binary with the specified name to handle the provisioning of the requested capability.
For example, if you specify type: model, Compose will look for a Docker CLI plugin named docker-model or a binary named model in the PATH.
services:
ai-runner:
provider:
type: model # Looks for docker-model plugin or model binary
options:
model: ai/example-model
The plugin or binary is responsible for:
This information is then passed to dependent services as environment variables.
[!TIP]
If you're working with AI models in Compose, use the
modelstop-level element instead.
Using provider services in your Compose applications offers several benefits:
If you want to create your own provider to extend Compose with custom capabilities, you can implement a Compose plugin that registers provider types.
For detailed information on how to create and implement your own provider, refer to the Compose Extensions documentation.
This guide explains the extension mechanism that allows you to add new provider types to Compose.