DevOps & Infrastructure prompts

Write a production Dockerfile.

APPLICATION: [LANGUAGE, FRAMEWORK, VERSION]
HOW IT BUILDS: [BUILD COMMANDS]
HOW IT RUNS: [START COMMAND]
DEPENDENCIES: [SYSTEM PACKAGES NEEDED AT BUILD VS RUNTIME]
PORT: [PORT]
CONFIGURATION: [ENV VARS]
TARGET PLATFORM: [amd64 / arm64 / both]

Write a multi-stage Dockerfile that:

1. Uses a specific base image tag with a digest, never :latest. Explain the choice of base (distroless / alpine / slim / full) and its trade-off for this language.
2. Orders layers so that dependency installation is cached separately from source code. Dependency manifests copied and installed before application source.
3. Builds in one stage and copies only the artefacts into a minimal runtime stage.
4. Runs as a non-root user, created explicitly.
5. Contains no secrets. Explain how secrets should be provided at runtime instead.
6. Includes a .dockerignore - list its contents explicitly. This is the most commonly forgotten file and the most common cause of bloated images and leaked .env files.
7. Sets a HEALTHCHECK appropriate for this application.
8. Handles signals correctly so the container stops promptly - explain whether this language runtime needs an init process (tini or similar) and why.
9. Pins dependency versions via a lockfile, and fails the build if the lockfile is out of date.

For each decision, one line explaining why.

Then give:
- The expected image size, roughly, and the biggest contributor
- THREE THINGS THAT WILL BITE YOU specific to this language's containerisation
- What to change for local development versus production

Design a CI pipeline.

PROJECT: [LANGUAGE, FRAMEWORK, WHAT IT IS]
CI PLATFORM: [GitHub Actions / GitLab CI / Jenkins / other]
CURRENT PIPELINE: [PASTE, or 'none']
TEST SUITE RUNTIME: [DURATION]
TEAM SIZE AND PR VOLUME: [DETAIL]
DEPLOY TARGET: [WHERE IT GOES]
MAIN PROBLEM: [too slow / flaky / does not catch enough / expensive]

Design the pipeline in stages, ordered by (speed x likelihood of catching something). Fast, high-yield checks first.

Suggested ordering, adjust for my stack:
1. Under 30 seconds: lint, format check, type check, secret scanning, dependency audit, commit message and branch checks
2. Under 5 minutes: unit tests, build
3. Longer: integration tests, e2e, container build and scan
4. On merge only: deploy, smoke tests

For each stage specify: what runs, why it is at this position, whether it blocks or warns, what it caches, and whether it can run in parallel with its neighbours.

Then address:
- CACHING - what to cache, the cache key, and how it gets invalidated. Cache keys that never invalidate are a common source of confusing failures.
- PARALLELISATION - what can run concurrently, and test splitting if the suite is slow
- WHAT RUNS ON WHICH TRIGGER - PR, main, tag, scheduled. Not everything needs to run on every push.
- FLAKY TEST POLICY - how to handle them without normalising retries
- REQUIRED VS OPTIONAL CHECKS - what should block a merge. Blocking on everything trains people to ignore failures.
- COST - anything expensive that runs more often than it needs to
- SECRETS - how they are provided, and how to avoid exposing them to pull requests from forks

Then the pipeline config for my platform.

End with: the three fastest wins for my stated main problem.

Review this infrastructure code before I apply it.

TOOL: [Terraform / Pulumi / CloudFormation / CDK / other]
CLOUD: [AWS / GCP / Azure / other]
ENVIRONMENT: [dev / staging / production]
WHAT THIS IS MEANT TO DO: [INTENT]

CODE:
```
[PASTE]
```

PLAN OUTPUT (if you have it):
```
[PASTE]
```

Review for:

1. DESTRUCTIVE CHANGES - anything in the plan that destroys or replaces a resource. For each: what is lost, whether it is recoverable, and whether there is a way to achieve the change without replacement. THIS IS THE FIRST AND MOST IMPORTANT SECTION.

2. SECURITY - overly permissive IAM (wildcards in actions or resources), security groups open to 0.0.0.0/0, public storage buckets, unencrypted storage or transit, secrets in plain text or in state, missing logging, default VPC use.

3. STATE SAFETY - anything that could corrupt or lock state. Remote state configured? Locking enabled? Any resource being imported or moved?

4. BLAST RADIUS - if this is wrong, what breaks and how widely. Does it touch shared infrastructure?

5. MISSING - backups, deletion protection on stateful resources, lifecycle rules preventing accidental destruction, tags for cost attribution and ownership, monitoring and alerts.

6. COST - resources that will cost meaningfully more than expected. Flag anything that scales with usage without a limit.

7. DRIFT AND MANUAL CHANGES - anything here likely to be changed manually later and then overwritten on the next apply.

8. RECOVERABILITY - if this apply goes wrong halfway, what state are we in and how do we get back?

End with: SAFE TO APPLY / APPLY WITH CARE (and what to watch) / DO NOT APPLY (and why).

For a production environment, be conservative. Flag anything you are unsure about rather than assuming it is fine.

Design alerting for this service.

SERVICE: [WHAT IT DOES]
WHO DEPENDS ON IT: [USERS/SYSTEMS]
SLA OR EXPECTATION: [IF ANY]
CURRENT ALERTS: [PASTE, or 'none']
CURRENT PROBLEM: [too many alerts / missing real problems / no alerts at all]
MONITORING STACK: [WHAT YOU HAVE]
TEAM SIZE AND ON-CALL SETUP: [DETAIL]

Apply this principle: alert on symptoms users experience, not on causes. CPU at 90% is not an alert; requests failing is.

Produce:

1. WHAT USERS ACTUALLY EXPERIENCE when this service degrades. List the failure modes from the user's perspective.

2. PAGE-WORTHY ALERTS - things requiring a human immediately, day or night. For each: the condition with a specific threshold and time window, why a human must act now, what they would do, and the runbook link. Aim for under five. If you propose more, justify each.

3. TICKET-WORTHY - real problems that can wait for business hours. Same structure.

4. DASHBOARD ONLY - useful signals that should never alert.

5. THRESHOLDS - for each alert, how to choose the threshold. Prefer error-rate and latency percentiles over absolutes. Use a time window to avoid single-spike noise. Say what the window should be and why.

6. DELETE THESE - from my current alerts, what to remove: alerts on causes rather than symptoms, alerts nobody acts on, alerts that fire and resolve on their own, duplicates of another alert.

7. MISSING COVERAGE - failure modes from section 1 with no alert. Include silent failures: a job that stops running, a queue that stops draining, a certificate about to expire, a disk filling slowly. These do not produce errors, so they produce no alerts.

8. ALERT ON ABSENCE - what should fire when something stops happening. Most alerting misses this entirely.

Rules:
- Every page-worthy alert must have a documented action. If there is no action, it is not an alert.
- Do not propose an alert without a specific threshold and window.

Write a deployment plan for this release.

WHAT IS BEING RELEASED: [DESCRIPTION]
WHY IT IS RISKY: [DATABASE CHANGE / BREAKING API / HIGH TRAFFIC / FIRST TIME / OTHER]
CURRENT DEPLOY PROCESS: [DESCRIPTION]
INFRASTRUCTURE: [WHERE IT RUNS, HOW MANY INSTANCES]
ROLLBACK CAPABILITY: [WHAT YOU CAN DO TODAY]
TRAFFIC PATTERN: [WHEN IS QUIET, WHEN IS PEAK]
DEPENDENT SYSTEMS: [WHAT ELSE IS AFFECTED]

Produce:

1. RISK ASSESSMENT - what specifically could go wrong, with likelihood and impact. Be concrete, not generic.

2. PRE-DEPLOY CHECKLIST - what must be true before starting: tests, staging verification, backups taken and verified restorable, feature flags in place, dependent teams notified, rollback tested, the right people available.

3. THE SEQUENCE - numbered steps with the exact command or action for each, and after each: what to verify before continuing, and how long to wait. Mark every irreversible step clearly and state it before the step.

4. FEATURE FLAG STRATEGY - if the change can be dark-launched or gradually enabled, describe the stages: internal only, 1%, 10%, 50%, 100%, with what to watch and how long to hold at each.

5. WHAT TO WATCH - the specific metrics, dashboards and log queries during and after. With the thresholds that mean stop. Define 'stop' as a number, decided now.

6. ROLLBACK PLAN - per step, how to undo. Include: the command, how long it takes, what is lost, and whether it works after the point of no return. If a step cannot be rolled back, say what forward-fix looks like instead.

7. THE ABORT CRITERIA - written now, before the adrenaline: the conditions under which you stop and roll back rather than pushing through. Make them numeric.

8. TIMING - when to do this, given my traffic pattern. Never at end of day or before a weekend.

9. COMMUNICATION - who to tell, before and after, and what to say if it goes wrong.

Section 7 is the most important. People push through failing deploys because nobody decided in advance what failure looked like.

My container will not start properly. Help me diagnose it.

PLATFORM: [Docker / Kubernetes / ECS / Cloud Run / other]
SYMPTOM: [crashloop / exits immediately / starts but unhealthy / hangs / OOMKilled]
LOGS:
```
[PASTE CONTAINER LOGS]
```
EVENTS / DESCRIBE OUTPUT (if Kubernetes):
```
[PASTE]
```
DOCKERFILE:
```
[PASTE]
```
CONFIG/MANIFEST:
```
[PASTE]
```
WORKS LOCALLY: [yes / no]

Work through causes in order of frequency for my stated symptom:

- EXITS IMMEDIATELY: the process is not long-running, the entrypoint is wrong, a shell form CMD swallowing the real command, the process backgrounding itself
- CRASHLOOP: application error on startup (check the logs' last lines before each restart), missing config, dependency not ready
- OOMKILLED: memory limit too low, a runtime heap setting that ignores the container limit (common on JVM and Node), a memory leak at startup
- UNHEALTHY: healthcheck hitting the wrong path or port, healthcheck timeout shorter than startup time, the app binding to 127.0.0.1 instead of 0.0.0.0
- PERMISSION DENIED: non-root user without permission on a mounted volume or a written path, read-only filesystem
- IMAGE PULL: registry auth, wrong tag, architecture mismatch (arm64 image on amd64 node)
- CONFIG: missing env var, secret or configmap not mounted, referencing a key that does not exist

For each: does it fit my evidence? Quote the log line or manifest field that supports or rules it out.

Then:
- THE TOP TWO causes with the specific command to confirm each
- THE FIX
- HOW TO GET MORE INFORMATION - the exact commands to run to see more, including how to get a shell in a container that will not stay up

If my logs are empty, that itself is a finding - explain what an empty log means for my symptom.

Help me reduce cloud costs.

CLOUD: [PROVIDER]
MONTHLY SPEND BREAKDOWN: [PASTE - BY SERVICE IF YOU HAVE IT]
WHAT THE INFRASTRUCTURE RUNS: [DESCRIPTION]
TRAFFIC PATTERN: [STEADY / SPIKY / SEASONAL / GROWING]
ENVIRONMENTS: [prod, staging, dev - and whether they run 24/7]
CONSTRAINTS: [SLA, COMPLIANCE, WHAT CANNOT CHANGE]

Produce:

1. WHERE THE MONEY GOES - ranked. Anything over 10% of spend gets its own analysis.

2. QUICK WINS - no architectural change, low risk. Check specifically for: non-production environments running outside working hours, unattached storage volumes, old snapshots and backups past their useful life, idle load balancers, unused static IPs, over-provisioned instances, forgotten test resources, logs retained far longer than anyone reads them, data transfer between zones that could be avoided, and NAT gateway data processing charges.
   For each: estimated monthly saving, risk, and the change.

3. RIGHT-SIZING - where the allocation exceeds actual use. Say what metric to check first, and warn about the trap: right-sizing on average utilisation breaks things at peak. Use peak.

4. COMMITMENT DISCOUNTS - reserved instances, savings plans, committed use. Only for genuinely steady workloads. State the lock-in and the break-even point, and warn against committing to a growing or changing architecture.

5. ARCHITECTURAL - bigger changes with bigger savings: storage tiering, caching to reduce egress or database load, autoscaling, spot or preemptible instances for fault-tolerant work. Each with effort, saving and risk.

6. DO NOT CUT THESE - spending that looks wasteful but is not: backups, redundancy, monitoring, security tooling, staging that mirrors production. Name them explicitly, because they are always the first things proposed.

7. THE ORDER - by (saving / risk), what to do first.

8. HOW TO KEEP IT DOWN - tagging for attribution, budgets and alerts, a periodic review, and what to check before adding anything new.

Rank by saving divided by risk, not by saving alone.