# kustomize create: Scaffold a kustomization.yaml

> kustomize create scaffolds a kustomization.yaml in the current directory. Reference for --resources, --autodetect, --namespace, and the file-exists errors in CI.

Source: https://latchkey.dev/learn/command-reference/kustomize-create  
Updated: 2026-06-30

kustomize create writes a new kustomization.yaml into the current directory so you can start an overlay or base.

Rather than hand-typing the file, create stamps out a valid kustomization.yaml. --autodetect picks up the YAML already in the folder.

## What it does

kustomize create generates a kustomization.yaml in the working directory. With no flags it writes an almost-empty file; --autodetect scans the directory for manifests and lists them under resources; --resources adds named files.

## Common usage

```Terminal
kustomize create
kustomize create --autodetect
kustomize create --resources deployment.yaml,service.yaml --namespace web
```

## Flags

| Flag | What it does |
| --- | --- |
| --resources <list> | Comma-separated files to add to the resources field |
| --autodetect | Add all YAML manifests found in the directory as resources |
| --recursive | With --autodetect, also descend into subdirectories |
| --namespace <ns> | Set the namespace field |
| --nameprefix / --namesuffix | Set namePrefix or nameSuffix |
| --annotations / --labels | Seed commonAnnotations or labels |

## In CI

create is for scaffolding, not pipelines. In CI you commit the kustomization.yaml and run kustomize build or kubectl apply -k against it. Pin the kustomize version on the runner so the generated file shape stays stable.

## Common errors in CI

"kustomization file already exists" means a kustomization.yaml is already present; create refuses to overwrite. "must build at directory: not a valid directory" later in the pipeline usually means create was never run or the file is named Kustomization with different casing than the loader expects (kustomization.yaml, kustomization.yml, or Kustomization).

## Using this in CI

A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.

```Terminal
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods

# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info

# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes
```

> Always set `--request-timeout` in CI. Without it an unreachable API server hangs until the job times out, which turns a thirty-second failure into a twenty-minute one.

## FAQ

### kustomize create: Scaffold a kustomization.yaml?

Rather than hand-typing the file, create stamps out a valid kustomization.yaml. --autodetect picks up the YAML already in the folder.

### What it does?

kustomize create generates a kustomization.yaml in the working directory. With no flags it writes an almost-empty file; --autodetect scans the directory for manifests and lists them under resources; --resources adds named files.

### In CI?

create is for scaffolding, not pipelines. In CI you commit the kustomization.yaml and run kustomize build or kubectl apply -k against it. Pin the kustomize version on the runner so the generated file shape stays stable.

### Common errors in CI?

"kustomization file already exists" means a kustomization.yaml is already present; create refuses to overwrite. "must build at directory: not a valid directory" later in the pipeline usually means create was never run or the file is named Kustomization with different casing than the loader expects (kustomization.yaml, kustomization.yml,

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt