Production Docker Deployment with Monitoring

Containers help when they reduce variance, not because they are fashionable

Docker is useful when you want one repeatable runtime across laptops, CI, and production. It becomes overhead when the container hides simple operational failures instead of clarifying them.

For Hermes, the production win is predictable packaging, environment isolation, and easier sidecar monitoring. Keep the stack small enough that you can still debug it under pressure.

When This Pattern Fits

  • You want the same runtime image across development, CI, and production.
  • You need environment isolation and cleaner dependency management than a host install.
  • You want to attach monitoring and reverse proxying without hand-managing every process.

Reference Workflow

  • Build one production image with only the runtime dependencies you need.
  • Compose Hermes with a reverse proxy and lightweight observability services.
  • Expose health checks and logs in a way operators can inspect quickly.
  • Roll new images gradually and keep old images available for rollback.
  • Step 1: Build a lean runtime image

    Multi-stage builds keep the runtime smaller and reduce surprise package drift. The image should contain the built app, runtime dependencies, and nothing else.

    FROM node:24-alpine AS deps
    

    WORKDIR /app

    COPY package*.json ./

    RUN npm ci

    FROM node:24-alpine AS runner

    WORKDIR /app

    COPY --from=deps /app/node_modules ./node_modules

    COPY . .

    RUN npm run build

    CMD ["npm", "start"]

    Step 2: Make health checks and metrics first-class

    A container that only β€œexists” is not healthy. Add HTTP health checks, structured logs, and at least one place where latency and failure counts are visible.

    Step 3: Promote images, not ad-hoc shell mutations

    If production fixes happen through shell commands inside a running container, rollback becomes guesswork. Build a new image, tag it, and deploy that artifact instead.

    Preflight Checklist

    • Use multi-stage builds and pin runtime dependencies.
    • Expose a real health check, not just an open TCP port.
    • Keep image tags and deployment history for rollbacks.
    • Monitor restart loops, memory pressure, and reverse proxy errors.

    Troubleshooting

    Do I need Kubernetes for Hermes?

    Not by default. Docker Compose or a simple container platform is enough for many teams until scaling, tenancy, or policy requirements become more demanding.

    What should Prometheus actually watch first?

    Start with process health, request latency, error rate, restart count, and resource pressure. Fancy dashboards can wait until the basics are reliable.

    What is the biggest Docker production mistake?

    Treating the container as an SSH host. Once operators hotfix inside containers, the image no longer reflects reality and rollbacks stop being trustworthy.

    Next Steps


    Last updated: April 14, 2026 Β· Hermes Agent v0.8