Last checked and updated on 05 Jun 2026
What Is New in Docker Engine 17.04
Docker Engine 17.04 CE (Edge) introduced significant updates focused on the builder, networking, and runtime. This release is packed with features that streamline the container build process and enhance multi-container application management.
| Category | Key Changes |
|---|---|
| New Features | Multi-Stage Builds, docker stack deploy for compose files |
| Improvements | Builder performance, docker service create update |
| Runtime & Daemon | Support for IBM Z (s390x), default seccomp profile on ARM |
| Deprecations | Hosting docs on Docker's infrastructure |
How did building Docker images get better?
Multi-Stage Builds are the headline feature. They let you use multiple FROM statements in a single Dockerfile to separate your build environment from your final, lean production image.
You can copy artifacts from one build stage to another, which means you no longer need messy shell scripting to clean up build tools and dependencies. This results in significantly smaller and more secure images. In practice, this simplifies Java, Go, or C++ workflows where the build toolchain is massive.
# First stage: the build environment
FROM golang:1.19 AS builder
WORKDIR /src
COPY . .
RUN go build -o /app .
# Final stage: the production image
FROM alpine:latest
COPY --from=builder /app /app
CMD ["/app"]What networking and orchestration updates were included?
The docker stack deploy command gained the ability to read standard Docker Compose files directly. This bridges the gap between local development with docker-compose and deploying the same application stack to a Swarm cluster.
We also saw updates to docker service create, making it more flexible for defining services. These changes made Swarm a more natural fit for deploying complex applications defined in Compose format, which is how many developers already work.
Were there any platform and runtime enhancements?
Yes, this release expanded Docker's architecture support by adding IBM Z (s390x) to the list of supported platforms. This opened up Docker for mainframe and large-scale enterprise systems.
On ARM platforms, the default seccomp security profile was enabled. This matters because it provides a stronger security baseline out-of-the-box for ARM-based deployments, like Raspberry Pi clusters or cloud ARM instances, aligning them with the security level of x86_64.
What was deprecated or removed in 17.04?
The main deprecation notice was for hosting documentation. Docker announced that future release notes and documentation would no longer be hosted on their own infrastructure at docs.docker.com.
This was an early signal of a shift towards storing documentation directly in the relevant GitHub repositories. For engineers, it meant the source of truth for docs was moving closer to the code itself.
FAQ
Why are Multi-Stage Builds such a big deal?
They solve the fundamental problem of creating bloated production images that contain all your build tools. By separating the build and runtime environments, you get final images that are smaller, have a reduced attack surface, and are faster to push and pull.
Can I use my existing docker-compose.yml file with `docker stack deploy` now?
In 17.04, yes, for many use cases. This command was enhanced to accept Compose files, making it much easier to take an application from local development straight into a Swarm production deployment without rewriting configuration.
What is the benefit of the default seccomp profile on ARM?
It hardens security automatically. Before this, ARM containers ran without the default seccomp filter that restricted dangerous system calls on x86_64. This change brought ARM security in line with other architectures by default.
Is Docker Engine 17.04 a stable release?
No. The 17.04 release was part of the Edge channel, meaning it was for testing new features and gathering feedback. For production environments, you should have used the concurrent Stable release (17.03 at the time).
What does support for IBM Z (s390x) mean?
It means you could run Docker Engine and containers natively on IBM Z mainframe systems. This was a major step for enterprises with mainframe investments that wanted to modernize applications using container technology.