DevOps Prompts: Automate Docker, Kubernetes, and CI/CD Without Night Shifts
It's 2 a.m., the pager goes off, and a pod in production is in CrashLoopBackOff. You open a terminal, start grepping logs, and wonder why you didn't automate this. If that sounds familiar, you're not alone. DevOps engineers spend a huge chunk of their week on repetitive tasks: writing Dockerfiles, debugging YAML, tweaking pipelines, and firefighting incidents.
Large language models (LLMs) can take over much of this grunt work — if you prompt them correctly. Unlike generic "write me a Dockerfile" requests, the prompts below are battle-tested, specific, and include real commands, expected outputs, and the exact routine they eliminate. Each prompt targets a concrete DevOps pain point: from container optimization to Terraform modules and GitHub Actions pipelines.
Below is a curated set of 10 prompts that turn your LLM into a junior DevOps assistant that never sleeps — so you can. All examples use real, working syntax (Docker, Kubernetes, Terraform, GitHub Actions, GitLab CI). Copy, paste, adapt.
1. Dockerfile Generator with Multi-Stage Build and Security Hardening
Task: Create a production-ready Dockerfile from a simple app description, including multi-stage builds, non-root user, and minimal base image.
Prompt:
You are a Docker expert. Generate a production-grade Dockerfile for a [language/framework] application. Requirements:
- Use multi-stage build to minimize final image size.
- Use a non-root user.
- Pin base image versions (e.g., python:3.12-slim-bookworm).
- Copy only necessary files; use .dockerignore.
- Add HEALTHCHECK if applicable.
- Output the Dockerfile and a matching .dockerignore.
App details: [describe your app, dependencies, entrypoint].
Example usage:
For a FastAPI app with Poetry, the LLM returns:
FROM python:3.12-slim-bookworm AS builder
WORKDIR /app
RUN pip install poetry==1.8.2
COPY pyproject.toml poetry.lock ./
RUN poetry export -f requirements.txt --output requirements.txt
FROM python:3.12-slim-bookworm
WORKDIR /app
RUN useradd -m appuser
COPY --from=builder /app/requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
USER appuser
HEALTHCHECK CMD curl -f http://localhost:8000/health || exit 1
CMD ["uvicorn", "main:app", "--host", "0.0.0.0"]
Routine eliminated: Manual Dockerfile writing, security misconfigurations, and image bloat.
2. Kubernetes Manifest and Helm Chart Generator
Task: Generate Kubernetes YAML or a Helm chart for a microservice with best practices (resource limits, liveness/readiness probes, HPA).
Prompt:
Generate a Kubernetes Deployment and Service for a [app name] with [replicas] replicas. Include:
- Resource requests and limits (CPU/memory).
- Liveness and readiness probes on path /health.
- HorizontalPodAutoscaler targeting 70% CPU.
- Use image [image:tag].
Output as a single YAML file.
Example usage:
The LLM returns a complete manifest. You can then ask: "Convert this to a Helm chart with values.yaml." It produces a chart structure with templated values, saving hours of boilerplate.
Routine eliminated: Writing repetitive YAML, forgetting probes, and manual Helm scaffolding.
3. Debugging Kubernetes Pod Failures from Logs
Task: Diagnose why a pod is crashing using its logs and events.
Prompt:
You are a Kubernetes troubleshooting expert. Here are the logs and kubectl describe output for a failing pod:
[PASTE LOGS AND EVENTS]
Identify the root cause and suggest a fix. Provide the exact kubectl commands to apply the fix.
Example usage:
A pod shows OOMKilled. The LLM suggests increasing memory limits and offers:
kubectl set resources deployment myapp --limits=memory=512Mi
It also explains how to check kubectl top pods for actual usage.
Routine eliminated: Late-night log spelunking and guesswork.
4. CI/CD Pipeline for GitHub Actions
Task: Create a GitHub Actions workflow for testing, building, and deploying a Docker image to a registry.
Prompt:
Write a GitHub Actions workflow that:
- Triggers on push to main.
- Runs tests with [test command].
- Builds a Docker image and pushes to GitHub Container Registry.
- Deploys to Kubernetes using kubectl set image.
Use official actions and cache dependencies.
Example usage:
The LLM returns a .github/workflows/deploy.yml with steps for checkout, setup, test, build-push-action, and deploy. It includes caching for pip/npm.
Routine eliminated: Pipeline boilerplate and trial-and-error with YAML syntax.
5. GitLab CI Pipeline with Stages and Artifacts
Task: Generate a .gitlab-ci.yml for a multi-stage pipeline (build, test, deploy).
Prompt:
Create a GitLab CI configuration for a [language] project. Stages: build, test, deploy. Use Docker-in-Docker for building images. Cache node_modules or pip cache. Deploy only on main branch.
Example usage:
The LLM outputs a .gitlab-ci.yml with image: docker:latest, services: docker:dind, and job definitions. It also adds only: [main] for deploy.
Routine eliminated: Manual CI configuration and debugging pipeline failures.
6. Terraform Module for AWS Infrastructure
Task: Generate Terraform code for an AWS VPC with public/private subnets, NAT gateway, and security groups.
Prompt:
Write Terraform code (HCL) for an AWS VPC with:
- CIDR 10.0.0.0/16.
- Two public and two private subnets in different AZs.
- Internet Gateway and NAT Gateway.
- Security group allowing SSH from your IP and HTTP/HTTPS from anywhere.
Use variables for region and environment. Output subnet IDs.
Example usage:
The LLM returns main.tf, variables.tf, and outputs.tf. You run terraform init && terraform apply after reviewing. It also suggests using terraform fmt and tflint.
Routine eliminated: Writing HCL from scratch and looking up resource arguments.
7. Incident Postmortem from Logs and Metrics
Task: Draft a blameless postmortem from raw incident data.
Prompt:
You are an SRE. Here are logs, metrics, and timeline for an incident:
[PASTE DATA]
Write a blameless postmortem with: summary, impact, root cause, resolution, and action items. Use a professional tone.
Example usage:
The LLM produces a structured document that you can paste into Confluence. It highlights that a memory leak caused OOM kills and suggests adding memory profiling.
Routine eliminated: Hours of writing postmortems after exhausting incidents.
8. Docker Compose for Local Development
Task: Generate a docker-compose.yml for a multi-service app (web, database, cache).
Prompt:
Create a docker-compose.yml for a [framework] app with PostgreSQL and Redis. Include volume mounts for hot reload, environment variables from .env, and healthchecks. Expose web on port 8000.
Example usage:
The LLM returns a compose file with services, networks, and volumes. You run docker compose up and have a full dev environment.
Routine eliminated: Manual setup of local dependencies and inconsistent environments.
9. Terraform State Management and Remote Backend
Task: Configure remote state with S3 and DynamoDB locking.
Prompt:
Write Terraform backend configuration for AWS S3 with DynamoDB locking. Include the S3 bucket and DynamoDB table creation in a separate bootstrap configuration. Use variables for bucket name and region.
Example usage:
The LLM provides two sets of files: one for bootstrapping the backend, one for the main config with backend "s3" block. It explains how to run terraform init -migrate-state.
Routine eliminated: State file conflicts and manual backend setup.
10. Kubernetes Cost Optimization Audit
Task: Analyze resource requests/limits and suggest savings.
Prompt:
You are a Kubernetes cost optimization expert. Here is the output of `kubectl describe nodes` and `kubectl top pods`:
[PASTE OUTPUT]
Identify over-provisioned resources and suggest adjustments to reduce cost while maintaining performance. Provide exact kubectl commands to apply changes.
Example usage:
The LLM spots that many pods request 1 CPU but use 0.1. It suggests reducing requests and enabling HPA. You apply changes with kubectl edit deployment.
Routine eliminated: Manual capacity planning and cloud bill surprises.
These prompts cover the core DevOps routines: containers, orchestration, infrastructure as code, and CI/CD. They won't replace your expertise, but they will eliminate the repetitive parts that keep you up at night. Start with one prompt, adapt it to your stack, and iterate. The goal isn't to let AI run your infrastructure — it's to let it handle the boilerplate so you can focus on architecture and reliability. Try the Dockerfile prompt on your next project and see how much time you save. Your night shifts will thank you.
Comments