Zero-Downtime Micro-Frontend Deployments: Dockerizing & Orchestrating with Kubernetes

The Challenge of Scaling Enterprise Micro-Frontends

As web platforms scale to hundreds of thousands of daily active users and multi-team collaboration models, deploying frontend updates without introducing outages or cache mismatches becomes a critical operational requirement.

In a micro-frontend architecture powered by Module Federation, each remote application and the container host must be versioned, containerized, and deployed independently without taking down the user experience.

1. Multi-Stage Docker Builds for Frontend Services

Optimizing Docker image sizes directly reduces deployment latency, pod startup times, and network bandwidth in Kubernetes clusters. Here is our production-ready multi-stage Dockerfile using Node.js Alpine and Nginx:

dockerfile

# Stage 1: Build &amp; Bundle
FROM node:20-alpine AS builder
WORKDIR /app

# Leverage layer caching for dependencies
COPY package*.json ./
RUN npm ci --prefer-offline --no-audit

COPY . .
ENV NODE_ENV=production
RUN npm run build

# Stage 2: Minimal Production Nginx Image
FROM nginx:alpine AS runner
WORKDIR /usr/share/nginx/html

# Clean default nginx static files
RUN rm -rf ./*

# Copy build artifacts and custom reverse proxy config
COPY --from=builder /app/dist .
COPY nginx.conf /etc/nginx/conf.d/default.conf

# Run as non-root security context
USER 1001
EXPOSE 8080

HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
  CMD wget -qO- http://localhost:8080/healthz || exit 1

CMD ["nginx", "-g", "daemon off;"]

By separating the build environment from the runtime Nginx container, we reduced container image sizes from 1.1 GB to under 32 MB, speeding up container pull times in Kubernetes nodes by over 85%.

2. Kubernetes Deployment & Zero-Downtime Rolling Updates

To guarantee zero downtime during continuous deployments, we configure declarative Kubernetes manifests with maxSurge and maxUnavailable controls alongside readiness and liveness probes:

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: micro-remote-analytics
  labels:
    app: micro-remote-analytics
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 0
  selector:
    matchLabels:
      app: micro-remote-analytics
  template:
    metadata:
      labels:
        app: micro-remote-analytics
    spec:
      containers:
        - name: web
          image: registry.example.com/analytics-remote:v2.4.0
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 15
            periodSeconds: 10

3. Ingress Routing & Dynamic Remote Entry Resolution

Kubernetes Ingress controllers route traffic to individual micro-frontend pods based on route prefixes or domain sub-paths, allowing container host applications to dynamically consume remote entries without centralized redeployments: