Kubernetes Deployment YAML generator

Enter a name, an image, a replica count and optional resources to get an apps/v1 Deployment manifest. The output is checked by parsing it back, and it never leaves your browser.

By , Founder at SeaGit

Also used as the app label.

Pin a tag or digest. Avoid :latest.

Deployment YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: default
  labels:
    app: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.27
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 250m
              memory: 256Mi
            limits:
              cpu: 500m
              memory: 512Mi

Apply with kubectl apply -f deployment.yaml. The selector and the pod template labels are the same, as apps/v1 requires.

What the manifest contains

The output is a Deployment in the namespace you choose. The selector and the pod template share one label, app, set to the Deployment name. Each request and limit you enter is written to the container. Blank fields are left out, so the file contains only what you asked for.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.27

Before you apply it

  • Dry-run it first with kubectl apply --dry-run=server -f deployment.yaml.
  • Add a readiness probe before you send traffic to the pods, or the Service will route to containers that are still starting.
  • Pin the image to a tag you pushed or to a digest. A tag such as latest hides which build is running.
  • Set a request on every container you care about. Without one the scheduler cannot place the pod sensibly, and a namespace quota that counts requests will reject it.

Frequently asked questions

Which apiVersion should a Deployment use?

apps/v1. It is the stable Deployment API and the one the Deployment reference documents. Older examples that use extensions/v1beta1 or apps/v1beta1 will not apply on current clusters.

Why must the selector match the pod template labels?

In apps/v1 the selector is required, and it has to match the labels in spec.template.metadata.labels. The Deployment uses it to find the pods it owns. The selector cannot be changed after the Deployment is created, so choose the labels before the first apply.

What is the difference between a request and a limit?

The scheduler places a pod using its requests. A limit is the most the container may use. CPU above its limit is throttled. Memory above its limit gets the container OOMKilled. Leaving a limit blank means no cap, and leaving both blank makes the pod BestEffort.

Can I write 1G and 1Gi as the same thing?

No. 1G is 1,000,000,000 bytes and 1Gi is 1,073,741,824 bytes. Use Mi and Gi when you mean binary sizes, which is what most container memory settings are written in.

Does the generator send my manifest anywhere?

No. The YAML is built in your browser, checked by parsing it back, and shown on the page. Nothing is uploaded, and no account is needed.

Sources

Checked Sources checked 11 October 2026.

  1. Kubernetes: Deployment API reference (apps/v1) — The apiVersion and kind, the required selector and template fields, and the replicas field.
  2. Kubernetes: Deployments — How a Deployment manages ReplicaSets and pods, and how to apply one with kubectl.
  3. Kubernetes: Resource Management for Pods and Containers — CPU and memory requests and limits, and the units CPU (cores or m) and memory (E, P, T, G, M, k, Ki, Mi, Gi) accept.
  4. Kubernetes: Labels and Selectors — Why the selector and the pod template labels must agree.

Related docs and tools