A solo developer or a two-person team can now ship infrastructure that used to require a dedicated DevOps engineer. Not because the tools got simpler, but because the conversation got smarter. Instead of scrolling through the Kubernetes API reference at 1 a.m., you describe what you need and the model drafts a manifest, a Dockerfile, or a GitHub Actions workflow you can review and fix.
The catch: vague prompts produce vague YAML, and broken YAML in production is worse than no YAML. This roundup collects 12 prompts that work because they force specificity — version pins, resource limits, security contexts, rollback strategies. Each comes with a use case and an example. Treat them as a starting draft, not a finished commit.
Docker: From Dockerfile to Slim Image
Prompt 1 — Production-grade multi-stage Dockerfile
Task: Turn a language/framework into a lean, non-root, cache-friendly image.
Prompt:
Write a multi-stage Dockerfile for a [Python 3.12 / Node 20 / Go 1.22] app.
Requirements:
- final image runs as non-root user (UID 10001)
- dependency layer cached separately from source copy
- pin base image to a specific digest-friendly tag (e.g. python:3.12-slim)
- add HEALTHCHECK using [endpoint / command]
- no build tools in the final stage
Output only the Dockerfile plus a one-line comment per stage explaining why.
Why it works: naming the UID, the cache strategy, and "no build tools in final stage" removes the three most common review comments before they happen. Ask for comments per stage — it makes the diff reviewable by a teammate.
Prompt 2 — Shrink an image that grew to 1.5 GB
Task: Diagnose bloat without rebuilding blind.
Prompt:
Here is my Dockerfile: [paste]. The image is [size].
List every layer that adds size, ranked by estimated impact.
For each, give the exact line to change and the expected saving.
Do not suggest switching base images unless you justify it against my constraints: [glibc needed / musl ok / etc].
Example use: a Python image carrying build-essential in the final stage typically drops hundreds of megabytes once gcc is confined to the builder. The model will point at the apt-get install line, not guess.
Prompt 3 — docker-compose for a local stack
Task: Spin up app + database + cache with healthchecks and named volumes.
Prompt:
Write docker-compose.yml (Compose Spec, no `version:` key) for:
- app: builds from ./Dockerfile, depends_on db and redis with condition: service_healthy
- postgres:16 with named volume and env from .env
- redis:7-alpine with appendonly yes
Add healthchecks for all three. Use env_file, not hardcoded secrets.
Tip: the version: top-level key is obsolete in the Compose Specification — omitting it avoids a deprecation warning in newer Docker Compose releases.
docker compose up.
Kubernetes: Manifests and Helm Without the Guesswork
Prompt 4 — Deployment with sane defaults
Task: Generate a Deployment that a cluster admin won't reject.
Prompt:
Write a Kubernetes Deployment (apps/v1) for image [repo:tag].
Include: replicas 2, resources requests/limits, liveness and readiness probes,
securityContext with runAsNonRoot and readOnlyRootFilesystem,
and a PodDisruptionBudget. Explain each field you set in one line.
Why it matters: readOnlyRootFilesystem: true and runAsNonRoot are the fields most often missing from AI drafts unless you name them. The explanation line lets you catch a wrong assumption fast.
Prompt 5 — Debug a CrashLoopBackOff
Task: Turn logs and kubectl describe output into a diagnosis.
Prompt:
Pod is in CrashLoopBackOff. Here is `kubectl describe pod` output: [paste]
and last logs: [paste].
List the 3 most likely causes ranked by evidence in the output.
For each, give the command to confirm it.
Example: an OOMKilled exit code (137) plus a low memory limit points to a limit bump or a memory leak — the model should distinguish these by asking for kubectl top pod.
Prompt 6 — Scaffold a Helm chart
Task: Chart structure with values, helpers, and templating.
Prompt:
Create a Helm chart (apiVersion v2) named [name] with templates for Deployment,
Service, Ingress, and ConfigMap. Put image tag, replicas, and resources in values.yaml.
Use the standard _helpers.tpl naming convention (fullname, labels).
Show the resulting directory tree and the values.yaml.
Prompt 7 — Review a manifest before apply
Task: A second pair of eyes on hand-edited YAML.
Prompt:
Review this manifest for: missing resource limits, missing probes,
hostPath mounts, privileged: true, latest tags, and namespace omissions.
Output a table: issue
| severity | fix.
CI/CD: Pipelines That Fail Loudly and Roll Back
Prompt 8 — GitHub Actions with caching and matrix
Task: A test-and-build workflow that doesn't take 20 minutes.
Prompt:
Write .github/workflows/ci.yml for a [stack] project.
Jobs: lint, test (matrix over [versions]), build image and push to GHCR on main only.
Use actions/cache for dependencies, pin actions to major versions,
and set permissions: contents: read, packages: write.
Note: pinning permissions is a real security control — the default GITHUB_TOKEN is often broader than a build needs.
Prompt 9 — GitLab CI equivalent
Task: Port a GitHub workflow to .gitlab-ci.yml.
Prompt:
Convert this GitHub Actions workflow to GitLab CI: [paste].
Use stages, cache with key based on lockfile, rules: instead of only/except,
and artifacts for test reports. Keep image versions identical.
Prompt 10 — Terraform for a managed cluster
Task: Infrastructure as code without provider-version drift.
Prompt:
Write Terraform (>= 1.6) for a [EKS/GKE] cluster with a managed node group.
Pin the provider version, use variables for region and node count,
add a remote backend block for S3 + DynamoDB locking (commented placeholders are fine).
Run through `terraform plan` mentally and flag anything that would force replacement.
Why it helps: "flag anything that would force replacement" catches the classic trap of changing an immutable field and silently recreating a database.
terraform validate and a plan review before apply. Treat plan output as the source of truth, not the model's confidence.
Monitoring and the Human in the Loop
Prompt 11 — Alert rules that don't page at 3 a.m. for nothing
Task: Prometheus alerting rules with sensible thresholds.
Prompt:
Write Prometheus alerting rules for: high error rate, high latency (p95),
and pod restart loops. Use `for:` durations to avoid flapping,
and add a runbook_url annotation placeholder. Explain each threshold choice.
Prompt 12 — The pre-commit review prompt
Task: Catch what the first 11 prompts missed.
Prompt:
Act as a senior SRE reviewing these files: [paste Dockerfile, manifests, workflows].
List only issues that would cause an outage, a security finding, or a failed deploy.
No style nits. Output as a checklist I can paste into a PR.
What This Actually Replaces — and What It Doesn't
| Area | AI handles well | You still own |
|---|---|---|
| Dockerfiles | Boilerplate, multi-stage, slimming | Base image security policy |
| Kubernetes | Manifest syntax, probes, review | Cluster capacity, blast radius |
| CI/CD | Workflow structure, caching | Secrets management, approvals |
| Terraform | Module scaffolding, plan flags | State backend, real apply |
| Monitoring | Rule syntax, thresholds | What actually matters to users |
The pattern is consistent: the model removes the recall tax — remembering the exact field name, the right API version, the caching key — while you keep the judgment calls. For solo developers this is the difference between shipping on Friday and shipping next month.
Start with Prompt 12 as a habit: run every generated file through the SRE review prompt before it touches a cluster. Then pick one area — Docker or CI — and rebuild it this week with the prompts above. Your future on-call self will thank you.
Comments