Back to basics: A reminder for building smaller images, safer builds, in the agentic workspace.

An enterprise team deploying an identity service has a familiar problem: a new release works, but recovery and scaling take longer than expected. The container image includes the compiler, development files, and other components that were needed to build the service but are unnecessary once it is running.

Now imagine an AI coding agent generated that image. The Dockerfile may look reasonable, the pipeline may pass, and the application may respond. None of those outcomes, by itself, tells the organization what entered the image, what the agent could access, or whether the deployment platform can safely run it.

Docker image optimization is an engineering discipline that connects image size, software supply chain security, and operational reliability. The goal is to ship the components a service needs, verify how they were assembled, and control the systems that build and run them.

Why Docker image size matters in enterprise environments

Images are templates used to create containers. They consist of layers that container tooling can store, transfer, and reuse. When a new node lacks those layers, it must retrieve and unpack them before a container can start. Smaller images can reduce transfer and storage demands, especially when scaling across new nodes or recovering in another region.

The operational benefit depends on the environment. Registries transfer compressed layers, nodes may already have layers cached, and startup also includes scheduling, unpacking, initialization, readiness checks, and application dependencies. Measure end-to-end readiness instead of assuming that a smaller image will always start faster.

Removing unnecessary packages can also reduce the software that must be inventoried and maintained. It does not make the application secure: vulnerable dependencies, exposed credentials, unsafe permissions, and application flaws can remain in a very small image.

An enterprise example: an identity service under load

Consider a fictional healthcare organization running a Go-based service that validates access tokens for internal applications. During a regional failover exercise, new nodes must pull the service image before they can handle traffic. The original image includes the Go toolchain and the application source. Security teams must also review the additional packages shipped with every production deployment.

The team separates compilation from runtime, keeps trusted certificate authorities for outbound TLS connections, and runs the service as an unprivileged user. It records the original and revised image sizes, performs functional and security testing, and compares cold-node pull and readiness times across the same region and node type. Results are measurements for that environment, not universal benchmarks.

Use a multi-stage Docker build

A multi-stage Dockerfile builds the application in one stage and copies selected outputs into another. The following illustrative example assumes a Go module with go.mod and go.sum, an application at ./cmd/identity-service, and a statically linked Linux binary. Replace the version and base image digests with organization-approved values; verify the chosen images and update them through a controlled process.

# syntax=docker/dockerfile:1
FROM golang:<approved-version>@sha256:<builder-digest> AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -trimpath \
    -o /out/identity-service ./cmd/identity-service
FROM gcr.io/distroless/static-debian12:nonroot@sha256:<runtime-digest>
COPY --from=build --chown=65532:65532 \
    /out/identity-service /identity-service
USER 65532:65532
EXPOSE 8080
ENTRYPOINT ["/identity-service"]

Copying dependency manifests before the rest of the source helps the build cache reuse the dependency download when application code changes. EXPOSE documents the intended port; it does not publish a port or enforce network policy. The build image and runtime image are pinned by digest for traceability, but a pin alone does not keep them patched. Review and update those digests when approved fixes become available.

A minimal runtime is a design choice, not an automatic best choice. A scratch image has no shell, certificate bundle, or other files unless you add them. Some applications need certificate authorities, time zone data, dynamically linked libraries, or writable directories. Validate the actual runtime base and application behavior, including TLS, graceful shutdown, logging, and health checks. A shell-free image also requires a planned debugging method, such as an approved ephemeral debug container.

Keep unwanted files out of the build

A .dockerignore file limits what enters the build context. That reduces unnecessary transfers and helps prevent accidental inclusion of sensitive or irrelevant files. Tailor exclusions to the project and test that required files remain available:

.git
.env
.env.*
*.pem
*.key
node_modules/
coverage/
tmp/

Of course human users know not to copy credentials into the image or pass them through Dockerfile ARG or ENV instructions. Make sure your skill.md agent file has the same instructions and never assume the .gitignore file is correct- always check the .gitignore file.

When a build needs a private package credential, use a BuildKit secret mount and short-lived, least-privilege credentials. A secret mount reduces persistence in layers, but a malicious or careless build command can still copy, print, or transmit the secret. Review build instructions and restrict network access where practical.

Understand the build, runtime, and control environments

Build environment: Docker Buildx and BuildKit interpret build instructions, fetch base images and dependencies, and produce artifacts. A build can execute code from Dockerfiles and dependencies. The builder, its network access, caches, source inputs, and credentials therefore deserve the same scrutiny as the final image.

Runtime environment: A container runtime starts the image with specific permissions, mounts, network connections, and resource limits. Docker Engine can provide the runtime on a host; Kubernetes commonly uses containerd or CRI-O through its container runtime interface. The Dockerfile USER instruction helps establish a safer default, but deployment configuration can override it.

Control environment: Docker Engine has a daemon API used to manage containers and images. In Kubernetes, the control plane, including the API server, scheduler, and controllers, manages desired cluster state. These are distinct systems, not a single universal Docker control plane. Access to either management surface can have broad consequences. In particular, access to a rootful Docker daemon socket can effectively grant root-level control over its host. Rootless Docker reduces some daemon and runtime risks, but still requires access controls and careful configuration.

For production workloads, restrict management API access, protect service identities, avoid exposing the Docker socket to workloads, and use role-based access control and admission policies appropriate to the orchestrator. Configure non-root execution, restricted capabilities, read-only root filesystems where supported, and CPU and memory limits. Test these controls against application needs before enforcing them.

What changes when AI agents build container images?

An agent can write a Dockerfile, install dependencies, modify a pipeline, and request a build in minutes. That speed increases the value of clear boundaries: the agent may encounter untrusted repository content, package metadata, or logs that influence its next action. A prompt in an issue or source file is not authority to change a registry policy or extract credentials.

Give the agent a task-scoped identity and an isolated, preferably ephemeral builder. Limit access to approved repositories, registries, networks, and short-lived credentials. Separate the ability to propose changes from the ability to approve releases or deploy to production. A human or independently enforced policy should review sensitive changes to base images, permissions, network access, deployment manifests, and pipeline configuration.

Record the source revision, builder identity, dependencies, and image digest. Generate a software bill of materials (SBOM) and build provenance, scan images and dependencies, and sign the resulting artifacts with an approved signing system. An attestation is a claim, not proof by itself: verify signatures, trusted identity, provenance, and policy before deployment. Enforce those checks at the release or admission boundary, and retain the evidence needed to investigate later.

Measure optimization where operations feel it

Start with a baseline: image size, layer composition, vulnerability findings, and cold-node time from deployment request to application readiness. Use docker image inspect and docker history to investigate local images, and compare registry transfer sizes with local unpacked sizes rather than treating them as the same metric.

After the change, repeat the same tests on comparable nodes with explicit cache conditions. Track build duration, registry transfer, readiness time, failed deployments, and the time needed to patch and redeploy. Review scan findings for actual exposure and reachability; a smaller count is useful context, not a substitute for remediation. Keep an approved rollback image and confirm it works in a recovery exercise.

The decision belongs to the organization

Optimizing Docker images is a practical way to reduce unnecessary software in production and improve the predictability of deployments. The stronger outcome comes when teams can explain what an image contains, how it was built, which identities controlled its release, and how it behaves under production constraints.

As AI agents take on more of the build work, those questions become more urgent. If an agent produced the container image your critical service depends on, could your team trace what it included, verify who authorized its release, and recover it confidently under pressure?