Support for Multiple Build Contexts in Dockerfile with TestContainers

[nesherhh]

I have a Dockerfile that uses multiple build contexts with the COPY --from=<buildcontext> syntax. When building the image manually, I use the docker build command with the --build-context flag, like this:

docker build --build-context abc=/path/to/context1 --build-context xyz=/path/to/context2 -f Dockerfile .

However, I'm now trying to use TestContainers for .NET to automate my testing, and I can't find a way to specify multiple build contexts when building an image with ImageFromDockerfile.

My Questions:

1. Is there a way to specify --build-context for multiple build contexts directly in TestContainers for .NET?
2. If not, are there any plans to support this feature in the future?
3. What are the recommended workarounds for using multiple build contexts with TestContainers?

I’d prefer to keep my Dockerfile unchanged, as modifying it to merge contexts isn't an ideal solution for my use case.

Thanks for any guidance!

[ramonsolis11]

As of the current Testcontainers for .NET API, I don't see direct support for passing multiple named BuildKit contexts equivalent to:

docker buildx build
--build-context abc=/path/to/context1
--build-context xyz=/path/to/context2
.

There are two related APIs worth distinguishing:

ImageFromDockerfileBuilder uses the Docker Engine API and supports a single build context through WithContextDirectory(...).

BuildKitImageFromDockerfileBuilder uses docker buildx build and supports BuildKit-specific features such as secrets and SSH, but the builder currently does not appear to expose a WithBuildContext(name, path)-style API for named additional contexts.

For this scenario, I would consider three approaches.

1. Build the image externally with Buildx

If keeping the Dockerfile unchanged is important, this is probably the cleanest option.

Build the image before creating the Testcontainers container:

docker buildx build
--build-context abc=/path/to/context1
--build-context xyz=/path/to/context2
--load
-t my-integration-test:local
-f Dockerfile .

Then let Testcontainers consume the resulting image:

var container = new ContainerBuilder()
.WithImage("my-integration-test:local")
.Build();

await container.StartAsync();

This keeps the responsibility separated:

Buildx
└── builds image using multiple contexts
↓
Docker image store
↓
Testcontainers
└── starts/manages the test container

2. Use one common build context

If the directory structure permits it, another option is moving the build context high enough in the directory tree and using:

new ImageFromDockerfileBuilder()
.WithContextDirectory("/path/to/common/root")
.WithDockerfileDirectory("/path/to/dockerfile")
.WithDockerfile("Dockerfile");

This is simpler operationally, although it is not equivalent to named BuildKit contexts and may require changing COPY paths or .dockerignore.

3. Add first-class support to the BuildKit builder

Architecturally, the most natural Testcontainers API would be something similar to:

new BuildKitImageFromDockerfileBuilder("docker:...")
.WithBuildContext("abc", "/path/to/context1")
.WithBuildContext("xyz", "/path/to/context2");

which could translate internally to:

--build-context abc=/path/to/context1
--build-context xyz=/path/to/context2

That would preserve the existing Dockerfile and keep image lifecycle management inside Testcontainers.

So, for the current API, I would use external docker buildx build --load + ContainerBuilder.WithImage(...) when multiple named contexts are mandatory.

If maintaining the Dockerfile unchanged is a hard requirement, that solution also avoids flattening or copying multiple source trees into a synthetic context.