How to Use a Smaller Base Image in CI
Every megabyte of base image is pulled on a cold runner and pushed on a build. A leaner base cuts both without changing your code.
The base image sets a floor on build, push, and pull time. Slim, alpine, and distroless variants shrink that floor, but each trades away tooling you may rely on, so the choice is about fit, not just size.
1. Start from a slim variant
The -slim variants drop docs and extra packages while keeping glibc and a usable shell, the lowest-risk size cut.
FROM node:22-bookworm-slim
# vs node:22 (much larger, full toolchain)2. Go alpine when the toolchain allows
Alpine uses musl libc and is tiny, but native modules expecting glibc may break. Test before adopting.
FROM node:22-alpine
RUN apk add --no-cache git3. Use distroless for the final stage
A distroless runtime image has no shell or package manager, only your app and its runtime. Smallest and most secure, but you must do all build work in an earlier stage.
4. Measure the real cost: pull time
Image size matters because it is pulled cold. On Latchkey managed runners with warm base images, a smaller app layer still pulls faster, but the warm pool already removes most of the cold-pull penalty.
Key takeaways
- Slim variants are the lowest-risk size cut.
- Alpine is tiny but musl can break glibc-expecting native modules.
- Distroless final stages are smallest and most secure but need a separate build stage.