AI Prompts for Docker and DevOps Workflow Automation in 2026

I manage infrastructure for three production services and AI has significantly reduced the time I spend on Docker and CI/CD configuration. The tasks where it helps most: writing optimized multi-stage Dockerfiles, designing GitHub Actions workflows, and debugging cryptic Docker networking or permission issues. These prompts are tested in production environments with Node.js, Python, and Go services.

Optimized Dockerfile Prompts for Production Node.js and Python Services

The prompt that produces production-ready Dockerfiles: 'Write a multi-stage Dockerfile for a [Node.js 22 / Python 3.12] production service. Requirements: (1) separate build and runtime stages — the final image should contain only what's needed to run the service, no build tools, (2) use a non-root user for the runtime stage with appropriate file permissions, (3) order COPY instructions to maximize layer cache efficiency — dependencies before source code, (4) include a health check instruction appropriate for this type of service, (5) minimize final image size — recommend the appropriate base image and explain why (alpine vs slim vs standard), (6) handle secrets appropriately — do not use ENV for sensitive values, show where build args vs runtime env vars are appropriate. Show the complete Dockerfile with comments explaining security-relevant decisions.' Point 6 on secrets handling is the most security-critical element — AI frequently generates Dockerfiles with database passwords in ENV instructions, which bake secrets into the image history. The distinction between build-time ARG (acceptable for non-sensitive build config) and runtime env injection (required for all secrets) must be explicit.

For Node.js specifically, add: 'Use --omit=dev in the npm install for the production stage and set NODE_ENV=production. Show how to handle the case where some devDependencies are needed at build time but not runtime.' This is a specific Node.js pattern that AI often misses: build tools like TypeScript are devDependencies needed during build but must not appear in the final image.

• Multi-stage: build stage for compilation, runtime stage for minimal production image

• Non-root user in runtime stage — root in containers is a security issue

• COPY order: package.json first → install → then source files (maximizes cache)

• Secrets: never in ENV instructions — use runtime injection (K8s secrets, docker run -e)

• Node.js: --omit=dev in production stage + NODE_ENV=production

• Health check: /health endpoint check for APIs, process exit check for workers

GitHub Actions CI/CD Workflow Prompts for Automated Deployments

GitHub Actions workflows are notoriously fidgety to write from scratch. My prompt: 'Write a GitHub Actions workflow for a [type of project]. Requirements: (1) trigger on push to main and on pull request to main, (2) for PRs: run tests and linting, post results as a PR comment, (3) for merges to main: run tests, build Docker image, push to [ECR/GCR/Docker Hub] with [commit SHA and latest] tags, deploy to [staging/production] environment, (4) use environment secrets for all credentials — name the exact secrets I need to create in GitHub repository settings, (5) include a manual approval step before production deployment, (6) cache node_modules/pip packages with appropriate cache keys. Show the complete YAML with comments on non-obvious choices.' Naming the required secrets explicitly (point 4) is extremely practical — it prevents the common problem of forgetting a secret and only discovering it when the workflow fails at 2am. The manual approval step (5) uses GitHub Environments with protection rules, and AI usually shows the correct configuration for this when asked explicitly.

For Docker build optimization in CI, add: 'Use docker/build-push-action with cache-from: type=gha and cache-to: type=gha to use GitHub Actions' Docker layer cache. Show the complete build-push step.' GitHub Actions Docker layer caching reduces build time by 60-80% for typical services. It's not enabled by default and most CI tutorials don't show it.

• Separate triggers for PR (test only) and main push (build+deploy) in the same workflow

• Name required secrets explicitly — prevents deploy failures from missing secrets

• GitHub Environments with protection rules for manual approval before production

• Docker layer cache: docker/build-push-action with cache-from/to gha reduces builds 60-80%

• Tag strategy: commit SHA (pinnable) + 'latest' (convenience) for every build

• PR comment with test results: actions/github-script or a dedicated PR comment action