Docker 28.3 adds AMD device requests and environment credentials

A common command line interface does not make the host dependencies disappear. Docker 28.3 extends GPU requests to AMD through the existing device request machinery, but driver registration still depends on a helper executable. The implementation shows both the usefulness and the limits of presenting different hardware through the same flag.

The June 24 release notes pair this addition with native CLI support for DOCKER_AUTH_CONFIG. These changes concern two inputs often supplied by the environment around an application. One selects accelerator devices. The other supplies credentials used to retrieve or publish its image.

I value Docker's repeatable build and image model, but the host remains part of the execution contract. This release is useful because it provides explicit interfaces for inputs that an image cannot supply for itself. Reading the implementation also prevents the new flags from implying more portability than they provide.

AMD support uses the existing device request

The AMD support patch adds backend handling for the interface already used for NVIDIA GPUs. It introduces an AMD device driver registration and a function that updates the container process environment according to the device request.

The 28.3.0 AMD implementation makes that translation concrete. Explicit device identifiers become a comma-separated AMD_VISIBLE_DEVICES value. A positive device count becomes a list of numbered devices. A negative count selects all, while zero selects void.

The function also rejects a request that combines a nonzero count with explicit device identifiers. Those fields express different selection methods. Rejecting the combination avoids leaving the runtime to guess whether a count or a supplied list should control the result.

That mechanism is narrower than automatically supplying the entire accelerator stack. The Docker change translates a request into information the supported runtime can consume. It does not turn the application image into a source of host hardware or remove the need for the corresponding host integration.

The driver registration code looks for amd-container-runtime before registering the AMD handler. Finding the executable is therefore part of making this backend available. Merely upgrading a daemon on a host without that helper does not satisfy the registration condition.

There is also a specific ordering detail in this version. Registration first looks for the NVIDIA hook and returns after successfully registering it. The AMD helper check follows that return. On a host where the NVIDIA check succeeds, this initialization function does not proceed to AMD registration.

That is a reason to avoid describing the release as a universal mixed-vendor selection mechanism. The source supports a concrete AMD path with a concrete helper requirement. Its initialization order is part of the shipped behavior, even though the headline describes the interface at a higher level.

The shared count conversion also makes the abstraction visible. Asking for a number of devices becomes a list starting at zero. Asking for explicit identifiers bypasses that conversion. Those are distinguishable requests, so application deployment configuration should preserve which one it intends.

Registry credentials can come from the process environment

The CLI credential change makes DOCKER_AUTH_CONFIG a native credential source. Its value is a JSON object containing an auths map. Each registry entry supplies an auth field with a base64-encoded username and password or token pair.

The shape is intentionally restricted. The implementation uses a JSON decoder that rejects unknown fields. Separate username and password fields are not substitutes for the expected auth representation, even though those names may look familiar from other credential structures.

The following JSON illustrates the structure with the dummy pair user:pass. It is explanatory content, not a credential for any registry.

{
  "auths": {
    "registry.example.test": {
      "auth": "dXNlcjpwYXNz"
    }
  }
}

Base64 provides the representation expected by the parser. The encoded form is still the credential material, so its purpose should not be confused with encryption. The useful feature is supplying credentials through the calling process's environment without requiring that configuration to be represented only by the existing file or helper store.

The versioned configuration code shows the precedence. Docker first selects its ordinary file or configured native credential store. If the environment value is nonempty and valid, it wraps that store with an in-memory store initialized from the environment.

Lookups prefer the environment-backed values. A credential absent there can still come from the underlying store. This is an override with a fallback, so the presence of the environment variable does not mean every registry lookup ignores all existing configuration.

Malformed input has another important behavior. The CLI prints an error about creating the credential store and returns the underlying store. A parsing failure does not necessarily make every subsequent operation fail immediately. Existing credentials may still allow the requested registry operation to proceed.

That makes the diagnostic meaningful in automated environments. A successful pull alone cannot prove that the environment supplied the credentials actually used. It may have succeeded through the fallback. The parser's error identifies a configuration failure even when another credential source keeps the operation working.

Credential lifetime follows its source

An environment-supplied value belongs to the process environment. Treating a logout operation as deletion of that upstream value would overstate what a child process can change. A later CLI invocation receiving the same environment can construct the same credential source again.

For automated builds, the practical unit is therefore the invocation and its supplied configuration. Credentials can be injected for the process that needs them, but the system supplying that environment controls whether they appear again. That responsibility remains outside the image being pulled.

My preference is for application images to contain the runtime inputs they need, with registry access handled by the surrounding build or deployment process. Native environment credentials fit that division. The precedence and fallback rules still need to be understood so that an override has the intended effect.

The two additions in 28.3 share that dependence on an external provider. The daemon translates a GPU request after registering an available host backend. For credentials, the CLI translates a supplied object and combines it with an existing store. Each interface makes the request easier to express while leaving the source of the hardware or credentials explicit.