Following the introduction of Model Runner a few months ago, Docker Desktop 4.43 expands its capabilities with improved model management and broader OpenAI compatibility. The release also debuts a new Compose Bridge to simplify the generation of Kubernetes configurations and upgrade the Gordon AI agent.
Docker Model Runner in 4.43 introduces a new user interface for inspecting models through model cards. These cards summarize all available variants within a model family, detailing their features such as number of parameters, quantization, format, size, and architecture.
For developers preferring to work from the command line, the docker model
command now supports inspecting, monitoring, and unloading models. At the Docker Compose level, developers can now specify the context size to use for a given model as well as the llama.cpp runtime flags. Furthermore, Model Runner adds support several OpenAI API options, including tool support using {“stream”: “true”}
and improved compatibility and security with custom CORS configuration.
Docker Desktop 4.43 also upgrades the Gordon AI agent, adding support for multi-threaded conversations and delivering a 5x performance improvement.
You can now run multiple distinct conversations in parallel and switch between topics like debugging a container issue in one thread and refining a Docker Compose setup in another, without losing context.
Compose Bridge is a new feature that enables converting compose.yaml files to Kubernetes configurations using a single command:
docker compose bridge convert
This innovation automatically generates comprehensive Kubernetes resources, ensuring that local development environments can be quickly and accurately mirrored in production-like Kubernetes clusters.
Compose Bridge is able to automatically create namespaces, configuration maps, deployments, services, secrets, network policies, and persistent volumes based on Compose file declarations. Developers can adjust how Compose Bridge creates Kubernetes resources by customizing a set of template files. To this aim, you can either export the template files used by the default transformation and modify them or build your own templates for resources not managed by the default transformation.
The compose.yaml model may not offer all the configuration attributes required to populate the target manifest. If this is the case, you can then rely on Compose custom extensions to better describe the application, and offer an agnostic transformation
For example, this lets developers add the x-virtual-host
metadata to a Compose file and define how it should be translated into Kubernetes configuration by setting a custom ingress attribute in a custom template file. Using custom template files requires re-packaging the Docker image used by Compose Bridge.
As a final note on Docker Desktop 4.43, the MCP Toolkit now supports OAuth and offers improved integration with GitHub and Visual Studio Code.