How to Use AI for DevOps: Docker, CI/CD, Shell Scripts

DevOps work is high-leverage and high-risk: a tiny line in a Dockerfile or a missing flag in a shell script can balloon image sizes, leak secrets, or wipe a server. AI is fast at producing these artefacts — and the prompt pattern below is how you keep speed without sacrificing safety.

1. Introduction

From a prompting perspective, DevOps work breaks into three families: containerisation (Dockerfiles, compose files), continuous integration and delivery (GitHub Actions, GitLab CI, CircleCI), and shell scripts (bash glue, deploy scripts, backup scripts). All three benefit from the same approach: tell the AI exactly which environment, which version, and which guardrails apply.

2. The Concept Explained

DevOps prompts go wrong because the AI does not know what is already in your environment. It defaults to "common practices" — which often means Ubuntu 22.04, bash, GitHub Actions on Linux runners, and the latest tag of every image. Those defaults sometimes match your reality and sometimes do not. Spelling out the environment removes the guessing.

The right mental model: AI is a fast SRE who just joined the team, has no SSH access, and only knows what you tell them. Anything implicit will be assumed — usually wrong.

3. The Problem Without This Technique

Without context, DevOps prompts produce broadly correct but specifically wrong outputs. The Dockerfile uses the latest base image. The CI workflow uses inputs that don't exist. The shell script assumes GNU coreutils on macOS.

write a dockerfile for my node app

4. The Solution

App: Node.js 20 TypeScript REST API. Source in `src/`, compiled to `dist/`
via `npm run build`. Uses Prisma (needs `prisma generate` step).
Entry: node dist/server.js. Listens on $PORT (default 3000).

Produce a multi-stage Dockerfile with:
- Base: node:20-alpine (pinned digest is fine if you suggest one)
- Stage 1 (deps): install only production deps with `npm ci --omit=dev`
- Stage 2 (build): install dev deps, compile TS, run prisma generate
- Stage 3 (runtime): copy node_modules from deps stage + dist from build
  stage. Non-root user. EXPOSE 3000. HEALTHCHECK using wget to /health.
- Cache mounts via BuildKit syntax if helpful.
- Final image < 200MB if possible. Add brief inline comments.

Output: only the Dockerfile. No README.

Repo: monorepo with a Node 20 app in `apps/api`.
Trigger: on push to main + pull_request to main.
Required secrets in the org: DOCKER_USER, DOCKER_PASS, GHCR_TOKEN.

Generate a GitHub Actions workflow that:
- Caches npm and Prisma client
- Runs lint, type-check, unit tests (jest), and integration tests
  (require a Postgres service container, postgres:16)
- Builds the Docker image only on main, tagged with both `latest` and
  the short SHA. Pushes to ghcr.io/${{ github.repository }}.
- Fails the workflow if any job fails. Notifies on failure to a Slack
  webhook stored in SLACK_WEBHOOK_URL secret.

Use ubuntu-latest runners. Pin action versions to majors (e.g. @v4).
Output: only the YAML file at .github/workflows/ci.yml.

Target shell: bash (assume /usr/bin/env bash, GNU coreutils on Linux only,
not macOS).

Write a script `scripts/backup-db.sh` that:
- Takes one positional arg: the environment name (e.g. staging, production)
- Reads $DB_URL_STAGING or $DB_URL_PRODUCTION from env based on the arg
- Runs pg_dump with --no-owner --no-acl and gzips the output
- Names the file: backups/YYYY-MM-DD_HH-MM_${env}.sql.gz (UTC)
- Uploads the file to s3://my-backups/${env}/ via aws s3 cp
- Deletes local backup file on success
- Exits non-zero with a clear message if pg_dump or aws s3 cp fails
- Uses `set -Eeuo pipefail` and a trap-based error handler that prints
  the failing line number

Output: only the bash script with a shebang and brief inline comments.

5. Step-by-Step Breakdown

1. State the runtime precisely. Node 20, Python 3.11, Ubuntu vs Alpine. Versions cascade through everything else.
2. Specify the CI provider and runner type. GitHub Actions on ubuntu-latest behaves differently from GitLab on a custom runner.
3. List the secrets and env vars by name. If they don't already exist in your environment, the AI will fabricate plausible names.
4. State the safety rules. Pin base images, pin action versions, use non-root users, set set -Eeuo pipefail in bash. Mention these explicitly.
5. Demand a size or duration target. "Image under 200MB" or "build under 5 minutes" pushes the AI to make trade-offs it wouldn't make by default.
6. Test the output in a throwaway environment first. DevOps mistakes are expensive when they hit prod. A 30-second sandbox run prevents 30-minute outages.

Tip: For shell scripts, always tell the AI which platform you're running on. macOS BSD sed and GNU sed have subtly different syntax — a script that works in CI may fail on a teammate's MacBook because of one flag.

6. Practice Exercises

7. Key Takeaways