What API version does the generated Deployment use?

It uses apps/v1, the only Deployment API version supported by Kubernetes since 1.16 and the version every currently supported cluster expects.

How does the tool pick the selector labels?

The Deployment's spec.selector.matchLabels and the Pod template's metadata.labels are both set to app: plus any extra labels you add, so the selector always matches the Pods it creates. Kubernetes requires selector labels to be immutable after creation, so decide on them before you apply the manifest.

What happens if I leave a resource request or limit blank?

Blank CPU/memory fields are omitted entirely from the generated resources block rather than written as empty strings, since an empty value there would be invalid YAML for Kubernetes' resource quantity format.

Does this tool validate that my image reference exists?

No, and it never contacts a registry or a cluster. It only checks that the image field isn't empty; whether the tag or digest actually exists is between you and your container registry.

Kubernetes Deployment Generator - Build Deployment YAML

Overview

Introduction

A Deployment is the workload object most teams reach for first, and hand-writing one correctly means remembering the exact nesting of selector, template, resources, and probes every single time.

This tool turns that into a form: fill in the image, replicas, ports, env vars, resource limits, and probes, and it assembles a ready-to-apply Deployment manifest, entirely client-side.

What Is Kubernetes Deployment YAML Generator?

A Kubernetes Deployment YAML generator that builds an apps/v1 Deployment manifest from structured form inputs rather than free-hand YAML editing.

It covers the fields teams actually use day to day: container image and replica count, one or more container ports, repeatable environment variables, CPU/memory requests and limits, HTTP liveness and readiness probes, a rolling update strategy, and custom labels.

How Kubernetes Deployment YAML Generator Works

Each form field maps directly to a field in the Deployment spec: the image and replica count populate spec.template.spec.containers[0].image and spec.replicas, ports and env vars become their respective array entries, and resource fields are grouped under spec.template.spec.containers[0].resources.requests/limits only when you actually provide a value.

The Pod template's labels and the Deployment's selector are kept in sync automatically, since Kubernetes requires they match for the Deployment to ever find and manage its Pods.

The output is a plain YAML string built directly by this tool, no YAML library, no network call, and no cluster access; nothing you type ever leaves your browser tab.

When To Use Kubernetes Deployment YAML Generator

Use it when scaffolding a new service's Deployment and you'd rather fill in fields than remember exact YAML indentation and key names.

It's also useful for quickly producing a variant of a Deployment, for example bumping replicas or changing a probe path, without opening a text editor.

It is not a substitute for `kubectl apply --dry-run=server` or a schema validator; always review the generated YAML and validate it against your cluster before shipping it.

Often used alongside Kubernetes Service YAML Generator, Kubernetes HorizontalPodAutoscaler YAML Generator and Kubernetes PodDisruptionBudget YAML Generator.

Features

Advantages

Covers the fields most real-world Deployments need: env vars, resources, probes, rolling update strategy, and labels, not just the bare minimum.
Keeps selector and Pod template labels consistent automatically, avoiding a common hand-written-YAML mistake.
Runs entirely client-side; no manifest content is transmitted anywhere.

Limitations

Only supports a single container per Pod; multi-container Pods (sidecars, init containers) need manual editing afterward.
Probes are HTTP GET only; TCP socket and exec probes aren't covered by this form.
Doesn't validate the image reference against a real registry, and doesn't dry-run the manifest against a cluster.

Examples

A minimal two-replica Deployment with a liveness probe

Input

name: web, image: nginx:1.25, replicas: 2, containerPort: 80, livenessProbe: path=/healthz port=80

Output

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  labels:
    app: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.25
          ports:
            - containerPort: 80
              protocol: TCP
          livenessProbe:
            httpGet:
              path: /healthz
              port: 80
            initialDelaySeconds: 10
            periodSeconds: 10

Only the fields you fill in appear in the output; resources and env vars are omitted entirely when left empty.

Best Practices & Notes

Best Practices

Always set both a liveness and a readiness probe for anything user-facing; a Pod that's up but not ready shouldn't receive traffic yet.
Set resource requests close to what the container actually uses in steady state, and limits high enough to absorb bursts without triggering an OOM kill.
Keep maxUnavailable at 0 or 25% for user-facing services so a rolling update never drops all serving capacity at once.

Developer Notes

The generator hand-builds the YAML string line by line rather than using a YAML serialization library, since the output only ever needs to represent this one fixed manifest shape. String scalars are quoted only when they'd otherwise be ambiguous (containing a colon, starting with a special character, or looking like a boolean/number/null), keeping the output close to what a human would hand-write. Kubernetes name validation follows the RFC 1123 DNS label subset Kubernetes enforces for most metadata.name fields: lowercase alphanumeric characters and hyphens, starting and ending with an alphanumeric character.

Kubernetes Deployment YAML Generator Use Cases

Scaffolding a new microservice's Deployment manifest before wiring it into a GitOps repo
Producing a quick variant of an existing Deployment (different replica count, image tag, or probe path) without hand-editing YAML
Teaching or demonstrating what a complete Deployment spec looks like field by field

Common Mistakes

Forgetting to set a readiness probe, so a Service starts routing traffic to a Pod before its process is actually ready to serve requests.
Setting a CPU limit far below the CPU request, which causes unnecessary throttling even when the node has spare capacity.
Changing selector labels on an existing Deployment, which Kubernetes rejects since matchLabels is immutable after creation.

Tips

Use the Kubernetes Service Generator next to expose this Deployment's Pods, matching its selector to the labels you set here.

Kubernetes Deployment YAML Generator