ShortIQ

ShortIQ

AI

50 AI Prompts for Docker and Kubernetes: Containers to Production

50 tested AI prompts for Docker and Kubernetes: writing production Dockerfiles, Docker Compose for local development, Kubernetes deployments, services, ingress, config maps, secrets, RBAC, and CI/CD pipelines.

June 11, 2026•ShortIQ Editorial Team

How to Get the Best Results from These Prompts

Docker and Kubernetes involve a lot of configuration that looks similar across projects but differs in critical details: base image versions, port numbers, resource limits, environment variable names, and namespace conventions. These prompts produce better output when you include your specific stack — what language your app uses, what ports it listens on, and what cloud provider you are deploying to.

For Kubernetes prompts especially, mention whether you are using a managed cluster such as EKS, GKE, or AKS, since ingress configuration, storage classes, and load balancer annotations differ between providers. Each prompt is designed to generate working YAML that you can adapt with minimal changes.

  • Specify your app language and base image preference (Alpine, Debian slim, distroless)
  • Include the port your application listens on in every Dockerfile prompt
  • For Kubernetes prompts, state your cloud provider and cluster version
  • Paste your existing Dockerfile or deployment YAML when asking for modifications

Dockerfiles and Multi-Stage Builds (Prompts 1-12)

Prompt 1: Write a production-ready multi-stage Dockerfile for a Node.js 20 Express application. Stage 1 installs all dependencies and transpiles TypeScript to JavaScript. Stage 2 starts from node:20-alpine, copies only the compiled output and production node_modules, creates a non-root user called appuser, sets NODE_ENV to production, exposes port 3000, and adds a HEALTHCHECK that calls GET /health every 30 seconds.

Prompt 2: Write a multi-stage Dockerfile for a Python FastAPI application. Stage 1 uses python:3.12-slim, installs build tools and Python dependencies into a virtual environment at /opt/venv. Stage 2 copies only the virtual environment and app source into a minimal image, runs as a non-root user, and starts the app with gunicorn and uvicorn workers. Prompt 3: Create a Dockerfile for a Next.js 14 application using the standalone output mode. Show how to configure next.config.js to enable standalone output, write the multi-stage build with the correct copy commands for the .next/standalone directory, and keep the final image under 150MB.

  • Prompt 4: Write a Dockerfile for a Go application. Use golang:1.22-alpine to build a statically linked binary with CGO disabled. Copy only the binary into a distroless or scratch final image. Show how to add CA certificates so the binary can make HTTPS requests without a full OS layer.
  • Prompt 5: Create a .dockerignore file for a Node.js project. Exclude node_modules, .git, test files, development config files, local environment files, coverage reports, and build artifacts that should not be in the image. Explain why each exclusion matters for build performance and security.
  • Prompt 6: Write a Dockerfile for a monorepo with a frontend (React) and backend (Node.js) package. Use a shared base stage that installs root dependencies, then a frontend build stage, a backend build stage, and a final production stage that runs only the backend but serves the frontend static files from the same container.
  • Prompt 7: Create a build argument pattern in a Dockerfile that allows switching between development and production builds using the same Dockerfile. Show how to pass the BUILD_ENV arg via docker build --build-arg and change the final CMD, installed packages, and environment variables based on its value.
  • Prompt 8: Write a Dockerfile that caches pip install or npm install more efficiently using layer ordering. Show the correct order of COPY commands so that the dependency install layer is only invalidated when the requirements.txt or package.json changes, not when application source code changes.
  • Prompt 9: Create a Dockerfile for a scheduled job container (a cronjob that runs a Python script). Include the cron daemon, mount the script from the COPY instruction, configure the crontab, and show how to redirect cron output to stdout so it is visible in docker logs.
  • Prompt 10: Write a Dockerfile that runs database migrations on startup before launching the main application process. Use a shell entrypoint script that runs the migration command, checks the exit code, and only starts the application if migrations succeed. Show how to handle the case where the database is not yet ready.
  • Prompt 11: Create a Docker image scanning step for a CI/CD pipeline using Trivy. Show the GitHub Actions step that builds the image, scans it for critical and high vulnerabilities, outputs a SARIF report, fails the pipeline if critical vulnerabilities are found, and ignores specific CVEs that have been reviewed and accepted.
  • Prompt 12: Write a Dockerfile that uses BuildKit cache mounts to speed up repeated builds. Show how to use --mount=type=cache for the npm cache directory and how to enable BuildKit in the Docker build command and in CI/CD environments.

Docker Compose for Local Development (Prompts 13-22)

Prompt 13: Write a docker-compose.yml for a full-stack Node.js application with PostgreSQL, Redis, and a background worker process. Include named volumes for database persistence, a healthcheck on the PostgreSQL service, depends_on with condition: service_healthy so the app waits for the database, and live reload via volume mounting the source directory into the Node.js container.

Prompt 14: Create a docker-compose.override.yml that adds development-only services and configuration to a base docker-compose.yml without modifying it. Include a pgAdmin service for database management, expose the Node.js debugger port, add verbose logging environment variables, and mount local SSL certificates. Prompt 15: Write a docker-compose.yml for a microservices architecture with three services: an API gateway, a users service, and an orders service. Use a custom bridge network so services communicate by service name. Show how to configure environment variables so each service knows the addresses of the others.

  • Prompt 16: Create a docker-compose.yml with profiles so you can start only a subset of services. Define a core profile with the app and database, a monitoring profile with Prometheus and Grafana, and a full profile that starts everything. Show the docker compose --profile command syntax.
  • Prompt 17: Write a docker-compose.yml for running end-to-end tests in CI. Use a service that runs the test suite, depends_on the app and database services, sets an exit code based on test pass/fail, and tears down all containers after the tests complete regardless of outcome.
  • Prompt 18: Create a Docker Compose setup for local HTTPS development using a self-signed certificate and Nginx as a reverse proxy. Show how to generate the certificate, configure the Nginx container to use it, and trust the certificate on macOS and Linux for browser development.
  • Prompt 19: Write a docker-compose.yml that mounts a local npm package as a volume for development. Show how to link a local package from a sibling directory into a Node.js container so changes to the package are immediately reflected without republishing.
  • Prompt 20: Create a docker-compose.yml for running database migrations and seeds as a one-off command using docker compose run. Show how to run the migration container with the correct environment, wait for the database to be ready, and remove the container after it exits.
  • Prompt 21: Write a Makefile with targets that wrap common docker compose commands: make up, make down, make logs, make shell (opens a bash shell in the app container), make migrate, make seed, and make clean (removes volumes and images). Include help text for each target.
  • Prompt 22: Create a docker-compose.yml for local Kafka development using the Bitnami Kafka image. Include a Zookeeper service, configure Kafka with a single broker, set up a kafka-ui service for topic management, and show a Node.js service that connects to Kafka using kafkajs.

Kubernetes Core Resources (Prompts 23-36)

Prompt 23: Write a Kubernetes Deployment manifest for a Node.js API with 3 replicas. Include resource requests (100m CPU, 128Mi memory) and limits (500m CPU, 512Mi memory), a liveness probe that calls GET /health every 10 seconds, a readiness probe that checks the same endpoint before routing traffic, a rollingUpdate strategy with maxSurge 1 and maxUnavailable 0, and a podAntiAffinity rule that spreads replicas across nodes.

Prompt 24: Create a Kubernetes Service manifest for a Node.js API. Write a ClusterIP service for internal cluster traffic, a LoadBalancer service for external access, and show how to annotate the LoadBalancer service for an AWS Network Load Balancer with a static IP. Explain when to use each service type. Prompt 25: Write a Kubernetes Ingress manifest using the Nginx ingress controller. Route traffic for api.yourdomain.com to the backend service and app.yourdomain.com to the frontend service. Enable TLS using a cert-manager certificate, configure rate limiting with Nginx annotations, and add CORS headers for the API routes.

  • Prompt 26: Create Kubernetes ConfigMap and Secret manifests for a Node.js application. Store non-sensitive config in the ConfigMap (APP_PORT, LOG_LEVEL, CORS_ORIGIN) and sensitive values in the Secret (DATABASE_URL, JWT_SECRET). Show how to inject them as environment variables in the Deployment and how to reference a specific key from each resource.
  • Prompt 27: Write a Kubernetes HorizontalPodAutoscaler manifest that scales a Deployment between 2 and 10 replicas based on CPU utilization (target 70%) and custom metrics from Prometheus (requests per second, target 500 rps). Include stabilization windows to prevent rapid scale-down.
  • Prompt 28: Create Kubernetes resource quota and limit range manifests for a namespace. The quota should cap the namespace at 4 CPU cores and 8Gi memory. The limit range should set default requests and limits for containers that do not specify them. Explain how these work together to prevent one team from consuming all cluster resources.
  • Prompt 29: Write a Kubernetes CronJob manifest that runs a database cleanup job every day at 3am UTC. The job should use a dedicated service account, set a concurrencyPolicy of Forbid to prevent overlapping runs, keep the last 3 successful and 1 failed job history, and set a deadline of 30 minutes.
  • Prompt 30: Create a Kubernetes Job manifest for running database migrations. The job should run before the Deployment using an initContainer pattern, use the same image as the application but a different command, fail the deployment if migrations fail, and ensure it only runs once per deployment using a unique name derived from the image tag.
  • Prompt 31: Write Kubernetes PersistentVolume and PersistentVolumeClaim manifests for a PostgreSQL StatefulSet. Use the appropriate storage class for your cloud provider, request 20Gi of storage, set the access mode to ReadWriteOnce, and show how the StatefulSet references the PVC template for automatic provisioning per pod.
  • Prompt 32: Create a Kubernetes NetworkPolicy that restricts traffic between namespaces. The API namespace can receive traffic from the ingress namespace only. The database namespace accepts connections from the API namespace only. All egress is allowed. Deny all ingress by default with a catch-all deny rule.
  • Prompt 33: Write a Kubernetes PodDisruptionBudget that ensures at least 2 out of 3 replicas of a Deployment remain available during voluntary disruptions such as node maintenance or cluster upgrades. Explain when PodDisruptionBudgets apply and when they do not.
  • Prompt 34: Create Kubernetes RBAC manifests: a ServiceAccount for a deployment pipeline, a Role that allows creating and updating Deployments and ConfigMaps in a specific namespace, a RoleBinding linking the ServiceAccount to the Role, and a ClusterRole for a read-only monitoring agent that can list pods and nodes across all namespaces.
  • Prompt 35: Write a Kubernetes StatefulSet for a Redis single-node instance with a persistent volume. Include a headless Service for stable pod DNS names, a ConfigMap with the Redis configuration, resource limits, and a readiness probe that runs redis-cli ping.
  • Prompt 36: Create Kubernetes liveness, readiness, and startup probes for an application that has a slow startup time (up to 60 seconds) but fast health checks once running. Show how to use the startupProbe to prevent the liveness probe from killing the pod during initialisation, and tune the failureThreshold and periodSeconds values.

CI/CD and Production Operations (Prompts 37-50)

Prompt 37: Write a GitHub Actions workflow that builds a Docker image, tags it with the git commit SHA and latest, pushes to a container registry, updates a Kubernetes Deployment in a staging cluster using kubectl set image, runs smoke tests against staging, and promotes to production by updating the production Deployment only after manual approval.

Prompt 38: Create a Helm chart for a Node.js API application. Include templates for Deployment, Service, Ingress, HorizontalPodAutoscaler, and ServiceAccount. Define values.yaml with sensible defaults for image tag, replica count, resource limits, ingress hostname, and autoscaling thresholds. Show how to override values for different environments using -f values-production.yaml. Prompt 39: Write a Kubernetes manifest for a blue-green deployment strategy without Helm. Show the two Deployment objects (blue and green), the Service that points to the active deployment using a label selector, and the kubectl commands to switch traffic from blue to green and back.

  • Prompt 40: Create a Kubernetes deployment strategy that uses readiness gates to hold traffic from a new pod until an external health check service confirms the instance is warmed up and ready to receive production traffic, beyond the standard readiness probe.
  • Prompt 41: Write a Prometheus ServiceMonitor manifest for scraping metrics from a Node.js application using the prom-client library. Include the correct labels for the Prometheus Operator to discover the monitor, configure scrape interval and timeout, and add a relabeling rule to add the namespace as a metric label.
  • Prompt 42: Create a Kubernetes pod security standard configuration that enforces the restricted policy across a namespace. Show the namespace labels required, what the restricted policy prevents, and how to create a legitimate exception for a specific workload that requires a capability the restricted policy would deny.
  • Prompt 43: Write a Kubernetes init container pattern for a web application that waits for a PostgreSQL service to be ready before the main container starts. Use a lightweight Alpine image with pg_isready or a loop checking the database port, set appropriate timeouts, and explain why init containers are better than application-level retry loops for this use case.
  • Prompt 44: Create a Kubernetes external secrets operator manifest that syncs secrets from AWS Secrets Manager into Kubernetes Secrets. Show the ClusterSecretStore connecting to AWS, an ExternalSecret that pulls a database connection string, and how the synced Kubernetes Secret is referenced in a Deployment.
  • Prompt 45: Write a Kubernetes node affinity and taint/toleration configuration that schedules GPU workloads only on nodes with GPU hardware, prevents non-GPU workloads from running on those nodes, and allows a specific monitoring DaemonSet to run on all nodes including the GPU ones.
  • Prompt 46: Create a Kubernetes vertical pod autoscaler manifest for a memory-intensive batch processing job. Set it to Off mode so it only recommends resource values without automatically applying them, and show how to query the VPA recommendations to tune your resource requests and limits.
  • Prompt 47: Write a Kubernetes resource that uses a post-start lifecycle hook to register a service instance with an external service registry when a pod starts, and a pre-stop lifecycle hook to deregister it before the pod shuts down. Include the termination grace period configuration.
  • Prompt 48: Create a Kubernetes ConfigMap that stores Nginx configuration and mount it into an Nginx container. Show how to update the ConfigMap to change the Nginx config and trigger a rolling restart of the pods without changing the Deployment manifest.
  • Prompt 49: Write a Kubernetes pod topology spread constraints configuration that distributes 6 replicas of a Deployment evenly across 3 availability zones, with a maximum skew of 1 pod, and falls back gracefully when a zone has fewer available nodes.
  • Prompt 50: Create a Kubernetes admission webhook manifest using a Mutating Admission Webhook that automatically injects a sidecar container into every pod in a specific namespace. Show the MutatingWebhookConfiguration, the webhook service, and the TLS certificate setup required for the API server to trust the webhook.

FAQ

Do I need Kubernetes for a small application?

No. Kubernetes adds significant operational complexity and is most valuable when you have multiple services, need horizontal scaling, or require zero-downtime deployments across a team. For a single application with modest traffic, Docker Compose on a single VPS managed by systemd or a platform like Render or Railway is a better starting point. Add Kubernetes when you have a specific problem it solves, not preemptively.

What is the difference between Docker Compose and Kubernetes?

Docker Compose runs containers on a single host and is designed for local development and simple single-server deployments. Kubernetes runs containers across a cluster of multiple machines, handles automatic rescheduling when nodes fail, and provides production features like rolling updates, autoscaling, and service discovery. Docker Compose is simpler; Kubernetes is more powerful and more complex.

Should I use Helm or plain Kubernetes manifests?

Plain manifests are better when you are learning Kubernetes or managing a small number of applications. Helm is valuable when you need to deploy the same application to multiple environments with different configuration values, share application packaging with others, or manage complex application dependencies. Start with plain manifests, reach for Helm when you find yourself copying and editing YAML for different environments.

Which managed Kubernetes service should I choose?

Google Kubernetes Engine (GKE) is generally the most mature and developer-friendly with excellent Autopilot mode for minimal cluster management. Amazon EKS integrates well with other AWS services and is the right choice if you are already in the AWS ecosystem. Azure AKS is strong for teams using Azure Active Directory and Microsoft tooling. For cost-sensitive projects, DigitalOcean Kubernetes and Linode LKE are simple and affordable.

Related free tools

If you want to turn this topic into action, use one of ShortIQ's free tools for campaign planning, UTM structure, or QR distribution.

Continue Reading

Explore more guides on link shortener SaaS strategy, Bitly alternatives, and white label link management.

Free newsletter

Get new guides in your inbox

We publish practical guides on dev tooling, prompt engineering, marketing workflows, and deployment. No fluff — straight to the point.

No spam. Unsubscribe any time.

Was this article helpful?

Tell us if this guide solved the problem or what was still missing. We use this to improve the blog and only follow up if you explicitly allow it.

We use this to improve tutorials, examples, and technical depth.