Kustomize Build Preview

See what the deterministic Kustomize transformers do to your manifests without running kustomize build. Paste your base resources and a kustomization.yaml, and it applies namePrefix/nameSuffix, namespace, commonLabels and commonAnnotations (including the matching selector and pod-template labels), images (newName, newTag or digest) and replicas overrides, then renders the resulting YAML. Patches, generators and remote bases are intentionally out of scope and clearly flagged. It runs entirely in your browser.

How to use the Kustomize Build Preview

Paste your base manifests into the left box — multiple Kubernetes objects are fine, separated by --- as usual — and your kustomization.yaml into the right box. The preview parses both, applies the supported transformers in Kustomize's order, and renders the combined output. It's designed for the common case of checking "what will my labels and image overrides actually produce" before committing an overlay.

The transformers it applies are the deterministic, field-rewriting ones: namePrefix/nameSuffix on metadata names, namespace, commonLabels (also written into selectors, pod-template labels, and a Service's selector so the result still matches), commonAnnotations, images (newName, newTag and digest), and replicas. What it deliberately does not do is apply strategic-merge or JSON6902 patches, run configMapGenerator/secretGenerator (which compute content hashes), or fetch remote bases — those require the real Kustomize binary, and the preview shows an "Out of scope" note rather than guessing. For an authoritative build always run kustomize build ./overlay (or kubectl kustomize); use this tool for a fast, local, no-install sanity check of the transformer fields.

What Kustomize transformers do

Kustomize is the template-free customization tool built into kubectl. Instead of parameterizing manifests with a templating language, you keep plain YAML base manifests and layer overlays on top, where a kustomization.yaml declares transformations to apply. The result is rendered by kustomize build (or kubectl apply -k) into final manifests. The appeal is that the base files stay valid, applyable Kubernetes YAML with no placeholder syntax.

The transformations split into two groups. Transformers rewrite fields mechanically: namePrefix and nameSuffix decorate every resource name, namespace sets the namespace, commonLabels and commonAnnotations inject metadata everywhere it belongs (crucially also into label selectors and pod-template labels, so a Deployment still selects its Pods), and the images and replicas transformers override container images and replica counts by name. These are pure, predictable functions of the input — given the same base and kustomization, the output is fully determined — which is exactly why they can be previewed without the Kustomize binary. Generators and patches are the other group: configMapGenerator and secretGenerator create new objects and append a content hash to their names, and patches apply strategic-merge or JSON-patch edits. Those need Kustomize's full engine.

This preview implements the transformer group faithfully and stops at the boundary of the generator/patch group, flagging anything it skips. That scoping is deliberate: a tool that silently ignored a patch would give you a confident but wrong preview, which is worse than no preview. The label handling mirrors Kustomize's real behaviour — labels are added to metadata.labels, to spec.selector.matchLabels, to spec.template.metadata.labels, to a Service's spec.selector, and into a CronJob's nested job template — because getting selectors right is the part people most often need to verify. For overlays that rely only on these fields, the preview matches kustomize build; for overlays using patches or generators, run the real binary and treat this as a quick check of the parts it does cover.

Common use cases

  • Verify label propagation. Confirm commonLabels land in the selector and pod template so the Deployment still matches its Pods.
  • Check image overrides. See the exact image string an overlay produces from newName, newTag or a digest.
  • Preview a prod overlay. Inspect the namePrefix, namespace and replica changes before applying to a cluster.
  • Learn Kustomize. Experiment with transformer fields and watch the rendered YAML update, with no install required.

Frequently asked questions

Does this replace "kustomize build"?
No. It previews only the deterministic transformers (namePrefix/Suffix, namespace, commonLabels, commonAnnotations, images, replicas). It does not apply patches, run configMap/secret generators, or fetch remote bases, all of which require the real Kustomize engine. For an authoritative render, run "kustomize build" or "kubectl kustomize".

Why are patches and generators out of scope?
Strategic-merge and JSON6902 patches need Kustomize's full merge semantics, and configMapGenerator/secretGenerator compute content hashes and create new objects. Approximating them would risk producing output that differs from the real build, so the preview flags them with an "Out of scope" note instead of guessing.

Where do commonLabels get added?
Following Kustomize's behaviour, into each resource's metadata.labels, into spec.selector.matchLabels, into the pod template's metadata.labels, into a Service's spec.selector, and into a CronJob's nested job-template labels. This is what keeps a workload's selector matching its Pods after the labels are applied.

How are image overrides resolved?
For each container image matching an entry's name, a digest (if given) is applied as name@sha256:..., otherwise newTag replaces the tag, otherwise the existing tag/digest is preserved with any newName. This mirrors how the images transformer rewrites the image field.

Is anything uploaded?
No. Both the base manifests and the kustomization are parsed locally in your browser using a bundled YAML library. Nothing is sent to a server, so it is safe to paste internal manifests.