We're moving to a hardened Docker image. Here's what that means.

We're shipping a new hardened Docker image for Directus. It's a breaking change for some setups, so I want to explain what we built, why we built it, and what it means depending on how you run Directus.

Considerations for this change

We've had the same conversation with customers enough times that I stopped being surprised by it:

• they run a vulnerability scan against our Docker image,

• CVEs come back,

• we explain that the flagged packages aren't actually exploitable (which is usually true),

• they still can't ship until the finding is closed.

The packages generating most of those findings are OS-level tooling we've been including in the image but never call at runtime. The fix is to stop shipping them altogether.

The new hardened image runs on a minimal hardened base. "Hardened base" means we build on top of an image stripped down to what actually runs at runtime and nothing else. We chose to use Docker Hardened Images (DHI) for this base. The attack surface is smaller because there's less in the image.

Before shipping it, we wanted confidence on the two components where a security failure would actually matter: argon2 (password hashing), sharp (image resizing) and isolated-vm (for sandboxed extensions and Flows Run Scripts).

For argon2, the prebuilt musl binary wasn’t working (segfaulted) so we needed to build from source within our image. We’ve tested both argon2 and sharp across both CPU architectures, under concurrent load, with malformed inputs and detected no crashes or failures. The hardened image gets its own tag -dhi so nothing you're already using breaks.

Why we’re shipping two images

The hardened image approach removes something some of you depend on: the shell and the package manager inside the container.

If you build your own image on top of ours a hard cutover to the hardened image would break your setup with no notice, so we're not doing a hard cutover. Both images will publish from the same release.

The hardened image is available now under the -dhi tag. The standard image keeps publishing on its existing tags.

Roughly three months from now the hardened image becomes the default; the standard image stays available through the end of the year. After that it's hardened only.

Though we are fully focused on going hardened, the overlap period exists because we want to give people time to migrate on their own schedule.

What this means for your setup

If you run our image directly without modification, this is mostly not your problem. New deployments will pick up the hardened image automatically once it becomes the default (in roughly 3 months).

The one thing worth checking now: the standard image is also getting a security pass in this release, and that includes removing npm and npx (see below), which aren't needed at runtime. If anything in your pipeline calls those, it's worth catching before the default switches rather than after.

If you build on top of our image, start testing against the -dhi tag now. The hardened base means there's no shell and no package manager available inside the container, so any install steps currently happening inside your Dockerfile need to move out.

The pattern that works for most setups: build your extension on your machine or in CI, then mount the built folder into the unaltered hardened image at /directus/extensions.

The image itself stays unchanged, which means it's the least likely to break when we update it. If you're running a more complex build with custom packages, native modules, anything beyond mounting built files, the approach is the same in principle: do the build work in a separate stage, copy the output into the hardened image.

The key shift is that the hardened image is a runtime environment not a build environment.

Running fewer packages means fewer CVE findings. The scan gets shorter, fewer findings need written justification, and the compliance conversation gets easier.

References

For more technical details, see the GitHub PR

If you really wanted to add npm for your build image…

FROM directus:{version}

RUN apk add --update npm

FROM directus:{version}

RUN apk add --update npm

FROM directus:{version}

RUN apk add --update npm

FROM directus:{version}

RUN apk add --update npm