Alpine Linux for Containers

Why Alpine for Containers?

Alpine Linux is tiny. A base image is about 5 MB compared to Debian's 120 MB or Ubuntu's 80 MB. For containers, smaller means faster pulls, less storage, and a smaller attack surface.

Alpine vs Debian-slim

# Alpine: ~5 MB base
FROM alpine:3.21
RUN apk add --no-cache nodejs npm
# Total: ~60 MB

# Debian slim: ~80 MB base
FROM debian:bookworm-slim
RUN apt-get update && apt-get install -y --no-install-recommends nodejs npm && rm -rf /var/lib/apt/lists/*
# Total: ~180 MB

The difference compounds when you're running dozens of containers or pulling images across slow networks.

The musl Factor

Alpine uses musl libc instead of glibc. This is what makes it small, but it can cause compatibility issues:

# This works on Debian but might fail on Alpine
# if the binary is compiled against glibc
./some-precompiled-binary

# Common issues:
# - DNS resolution behaves differently
# - Some Node.js native modules need rebuilding
# - Python packages with C extensions may need musl-compatible builds

Most modern software handles musl fine. But if you hit a weird bug that only happens in Alpine, musl is usually the culprit.

Building Efficient Alpine Images

Multi-stage Builds

# Build stage
FROM alpine:3.21 AS builder
RUN apk add --no-cache build-base nodejs npm
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

# Production stage
FROM alpine:3.21
RUN apk add --no-cache nodejs
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY . .
USER node
CMD ["node", "server.js"]

Security Best Practices

FROM alpine:3.21

# Create non-root user
RUN addgroup -S app && adduser -S app -G app

# Install only what you need
RUN apk add --no-cache \
    nodejs \
    && rm -rf /var/cache/apk/*

# Run as non-root
USER app

Package Management

# Alpine uses apk (Alpine Package Keeper)
apk add --no-cache nginx

# Search for packages
apk search nodejs

# Package info
apk info -a nodejs

# The --no-cache flag avoids saving the index locally
# Important for keeping images small

When NOT to Use Alpine

• Debugging — Alpine's minimal tools make troubleshooting harder. No bash by default (it uses ash), no curl, no vi
• glibc-dependent software — some enterprise software requires glibc
• Machine learning — Python ML libraries (numpy, scipy, tensorflow) can have build issues on musl
• When image size doesn't matter — if you're running 3 containers, saving 100 MB each doesn't justify debugging musl issues

Practical Recommendations

Distroless Alternative

Google's distroless images are even smaller than Alpine — they contain only the application runtime, no shell, no package manager:

FROM gcr.io/distroless/nodejs22
COPY --from=builder /app /app
CMD ["server.js"]

The tradeoff: you can't exec into the container for debugging.

The Bottom Line

Alpine is the default choice for production containers when you want small, fast, secure images. Use Debian-slim when you hit musl compatibility issues or need a familiar debugging environment. Use distroless when you want the absolute minimum.

Master container workflows in our Docker Fundamentals course — build and optimize images in real labs.

---

Ready to go deeper?

This article is part of a hands-on learning path. Continue building your skills with Docker Fundamentals on CopyPasteLearn.