Generate a Kubernetes Deployment YAML

Fill in the image, replica count, port, and labels and get a valid Deployment manifest — with the selector matching the pod template labels, which is the part people get wrong.

Open this example in Kubernetes Helper

Open the tool, then paste the sample input below. Everything runs locally in your browser.

Open this example in Kubernetes Helper →

The problem

Hand-writing Kubernetes YAML is fiddly: indentation matters, and the Deployment selector must match the pod template labels or the rollout silently manages no pods. Generating the manifest from a few fields keeps the structure and selectors correct.

Sample input

Inputs
name: web
image: nginx:1.27
replicas: 3
containerPort: 80

Expected output

Deployment YAML (excerpt)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.27
          ports:
            - containerPort: 80

The spec.selector.matchLabels must equal the template's labels (app: web) or the Deployment manages zero pods.

How to do it

  1. Enter the deployment name and image.
  2. Set the replica count and container port.
  3. Add labels for the selector.
  4. Generate the Deployment YAML.
  5. Confirm the selector matches the template labels.

Common mistakes

  • A selector that does not match the pod template labels, so no pods are managed.
  • Wrong indentation, which makes kubectl reject the manifest.
  • Using the :latest image tag instead of a pinned version.
  • Omitting resource requests and limits.
  • Forgetting a Service, so the Deployment is not reachable.

Related tools

Related guides

FAQ

How do I generate a Kubernetes Deployment manifest?

Provide the name, image, replicas, port, and labels. The helper produces a valid Deployment with the selector wired to the pod template labels.

Why must the selector match the template labels?

A Deployment manages the pods whose labels match spec.selector.matchLabels. If they do not match the template labels, the Deployment controls zero pods.

Should I pin the image tag?

Yes. Pin a specific version rather than latest so rollouts are reproducible and you can roll back to a known image.

Do I also need a Service?

Usually yes. A Deployment runs the pods, but a Service is what makes them reachable inside or outside the cluster.

Is my manifest uploaded?

No. The YAML is generated locally in your browser. Nothing is sent to a server.

The manifest is generated locally in your browser. Nothing is uploaded.

Explore the full developer toolkit

Generate Kubernetes manifests, lint Dockerfiles, convert and validate YAML — plus every other utility.

Browse all developer tools →

Practical example and expected result

Fill in the image, replica count, port, and labels and get a valid Deployment manifest - with the selector matching the pod template labels, which is the part people get wrong. In practice, this is most useful when you need a quick, repeatable check on a Kubernetes or Helm manifest before adding it to a ticket, pull request, test fixture, or support note.

A realistic input for this workflow is name: web image: nginx:1.27 replicas: 3 containerPort: 80. The expected result should resemble apiVersion: apps/v1 kind: Deployment metadata: name: web spec: replicas: 3 selector: matchLabels: app: web template: metadata: labels: app: ..., with the same important values preserved.

Troubleshooting checklist

  • Confirm you copied the complete Kubernetes or Helm manifest and not only a partial line or truncated preview.
  • Run the local tool once with a safe sample, then repeat with the real data only if your team policy allows it.
  • Check quoting, escaping, whitespace, encoding, timestamps, and environment-specific values before trusting the result.
  • Before sharing output, remove secrets, tokens, cookies, customer data, and production hostnames that are not needed for the review.

Next useful steps