devopsLlama

Dockerfile Generation Prompt (LLaMA / Ollama)

Dockerfiles generated without guidance often use :latest tags, run as root, and copy the entire source tree before installing dependencies (which breaks layer caching). This prompt enforces production best practices by default: multi-stage builds, non-root user, specific tags, HEALTHCHECK, and cache-optimised layer order. The size estimate helps you catch accidentally large images before they slow down deployments. This variant is formatted for LLaMA / Ollama: Optimised for LLaMA 3, Mistral, and Ollama local models. Uses [INST] / <<SYS>> instruction format.

Prompt Template
[INST] <<SYS>>
You are a helpful, accurate, and detailed AI assistant. Follow the instructions carefully.
<</SYS>>

You are a DevOps engineer specialising in container optimisation and security.

Generate a production-ready Dockerfile for the following application:

Application type: {{app_type}}
Language/Runtime: {{runtime}} {{runtime_version}}
Build command: {{build_command}}
Start command: {{start_command}}
Exposed port: {{port}}
Environment variables needed: {{env_vars}}

Requirements:
- Use multi-stage build to minimise final image size
- Run as a non-root user
- Use a specific image tag (never :latest)
- Add HEALTHCHECK instruction
- Optimise layer caching (copy dependency files before source code)
- {{additional_requirements}}

After the Dockerfile, provide:
1. **Size estimate** — approximate final image size
2. **Security notes** — any remaining security considerations
3. **docker build and run commands** for local testing [/INST]

Variables

{{app_type}}Application type, e.g., "REST API", "static website", "worker process"
{{runtime}}Runtime, e.g., Node.js, Python, Go, Java
{{runtime_version}}Specific version, e.g., 20.11, 3.12, 1.22
{{build_command}}Build command, e.g., "npm run build", "go build -o app .", or "None" if no build step
{{start_command}}Command to start the application, e.g., "node dist/server.js"
{{port}}Port the application listens on
{{env_vars}}Required environment variable names (not values), e.g., "DATABASE_URL, JWT_SECRET"
{{additional_requirements}}Other requirements or "None"

Example

Input
app_type: REST API
runtime: Node.js
runtime_version: 20.11
build_command: npm run build
start_command: node dist/server.js
port: 3000
env_vars: DATABASE_URL, JWT_SECRET, PORT
additional_requirements: Must work on both amd64 and arm64
Output
FROM node:20.11-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production=false
COPY . .
RUN npm run build

FROM node:20.11-alpine AS runner
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production && npm cache clean --force
COPY --from=builder /app/dist ./dist
USER appuser
EXPOSE 3000
HEALTHCHECK --interval=30s --timeout=5s --start-period=10s   CMD wget -qO- http://localhost:3000/health || exit 1
CMD ["node", "dist/server.js"]

Related Tools

FAQ

Should I always use Alpine-based images?
Alpine images are much smaller (5 MB vs. 100+ MB for Debian-based images) and work for most applications. However, Alpine uses musl libc instead of glibc, which can cause compatibility issues with some native modules. If you encounter issues, use the -slim Debian variant instead.
How do I handle secrets in a Dockerfile?
Never embed secrets in a Dockerfile or build arguments — they appear in the image layers. Use Docker BuildKit secrets (--secret flag) during build, or inject secrets at runtime via environment variables.
Can this generate a docker-compose.yml too?
Add "Also generate a docker-compose.yml with a PostgreSQL service and the appropriate environment variables" to additional_requirements. The AI will produce both files.

Related Prompts