# Docker Container Host


Hosting endpoints in Docker containers provides self-contained artifacts that can be deployed to multiple environments or managed by orchestration technologies such as [Kubernetes](https://kubernetes.io/docs/home/). Cloud providers, such as [AWS](/architecture/aws/compute.md#platform-as-a-service-containers) and [Azure](/architecture/azure/compute.md#platform-as-a-service-containers), also offer container hosting solutions.

To create and host an endpoint in a Docker container, use the `dotnet new` template from the [ParticularTemplates package](/nservicebus/dotnet-templates/index.md). The generated project includes all required endpoint setup infrastructure, along with a `Dockerfile` needed to build and deploy a container hosting one endpoint.

## Template overview

The `nsbendpoint` template creates a project that contains all of the files necessary to build an endpoint that can be deployed to Docker if the **Docker container** hosting model is chosen.

See details on the [`dotnet new nsbendpoint`](/nservicebus/dotnet-templates/index.md#nservicebus-endpoint) command for more.




### license.xml

Each Docker container must include a `license.xml` file. A placeholder for this file is created when the template is used to generate a new endpoint project. Before building the Docker container, this placeholder must be replaced with a valid `license.xml`.

An endpoint running in Docker will look for the `license.xml` file in [the same locations](/nservicebus/licensing/index.md#license-management) as it would in any other hosting scenario. By default, the `dotnet new` template places the `license.xml` in the correct location within the Docker image.

### Dockerfile

This file contains the instructions for compiling the endpoint and creating the Docker image.

The endpoint will be hosted in a container that is based on the `mcr.microsoft.com/dotnet/core/runtime:3.1` image. After the image is built, it contains the compiled artifacts of the endpoint project and is configured to launch the endpoint when the container runs.


To compile the endpoint and build the Docker image, run the following command:

<!-- snippet: docker-build -->

```txt
docker build -f Dockerfile -t MyEndpoint ./..
```

<!-- endsnippet -->

This step compiles and publishes the endpoint in `Release` mode:

```
RUN dotnet publish -c Release -o /app
```

The compiled endpoint is then added to the Docker image, and the container is configured to start the endpoint when it runs:

```
COPY --from=build /app .
ENTRYPOINT ["dotnet", "MyEndpoint.dll"]
```

### Program.cs

The `EndpointConfiguration` for the endpoint is defined in the template using the `.UseNServiceBus(…)` method. The generated code includes `TODO` comments to guide further customization—these should be completed to configure the endpoint appropriately.

Additional methods are available to handle endpoint failures and exceptions. These should be modified as needed to suit the specific behavior of the endpoint.

## Reading application settings

Endpoints hosted in Docker use the same [.NET configuration system](/nservicebus/hosting/extensions-hosting.md#reading-application-settings) as any other host. Connection strings and other settings can be placed in `appsettings.json` and overridden at runtime using environment variables.

Environment variable names use `__` (double underscore) as the section separator. For example, to override `ConnectionStrings:Transport` from `appsettings.json`, set:

```
ConnectionStrings__Transport=host=rabbitmq
```

This is the standard approach for injecting environment-specific configuration into Docker containers and Kubernetes pods, without modifying the image. See the [.NET environment variable configuration provider documentation](https://learn.microsoft.com/en-us/dotnet/core/extensions/configuration-providers#environment-variable-configuration-provider) for details on the naming convention.