kubectl neat: Clean up Kubernetes YAML output

The problem

You want to inspect a Deployment. You run:

kubectl get deployment my-app -o yaml

And you get something like this:

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "3"
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"apps/v1","kind":"Deployment", ... 300 more lines of JSON ...}
  creationTimestamp: "2026-04-12T08:23:11Z"
  generation: 5
  managedFields:
  - apiVersion: apps/v1
    fieldsType: FieldsManager
    fieldsV1:
      ... 80 lines of field manager data nobody asked for ...
  resourceVersion: "4829103"
  uid: a3f2c891-bc12-4d7e-9f1a-003b22e81cc4
spec:
  ...

The actual spec you care about is buried under layers of auto-generated metadata, managed fields, last-applied configurations, and status blocks.

This is the raw Kubernetes API output. It is complete. It is also completely unreadable for most purposes.

Enter kubectl neat

kubectl neat strips out Kubernetes-generated noise and gives you back clean, human-readable YAML — closer to what you would write yourself.

Same Deployment, after neat:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: production
  labels:
    app: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:1.4.2
        ports:
        - containerPort: 8080

That is it. Clean, readable, usable.

It does not change what runs in the cluster — it only cleans what you see on stdout or in a file.

Installation

Via Krew:

kubectl krew install neat

Via Homebrew:

brew install kubectl-neat

Pair with kubectx and kubens so you export from the right cluster; use kubectl tree when you need ownership, neat when you need the manifest itself.

Basic usage

# Clean up a deployment
kubectl get deployment my-app -o yaml | kubectl neat

# Clean up a pod
kubectl get pod my-app-7d9f8b6c4-xk2p9 -o yaml | kubectl neat

# Clean up any resource
kubectl get <resource> <name> -o yaml | kubectl neat

# Save clean YAML to a file
kubectl get deployment my-app -o yaml | kubectl neat > my-app-clean.yaml

# Use the shorthand subcommand
kubectl neat get deployment my-app

What gets removed

kubectl neat removes fields Kubernetes adds automatically and that you almost never need when reading or copying a manifest:

• managedFields — internal field tracking used by server-side apply
• creationTimestamp — when the resource was created
• resourceVersion — internal versioning
• uid — unique identifier assigned by Kubernetes
• generation — revision counter
• annotations with kubectl.kubernetes.io/last-applied-configuration — the full JSON blob of the last applied state
• status block — current runtime state (not part of the desired spec)

What stays: what you actually wrote — labels, spec, container definitions, resource requests.

When is this actually useful?

Copying manifests to a new cluster. Export a resource, clean it with neat, apply elsewhere. No manual editing of fifteen auto-generated fields.

Code reviews. Share a clean YAML diff instead of a wall of API noise.

Documentation. Runbooks and internal docs with readable manifests.

Learning. In an unfamiliar cluster, neat output shows what matters — not what Kubernetes added internally.

Debugging spec issues. When something is misconfigured, reading the clean spec is faster than scrolling past managed fields.

For live debugging, stern and k9s still handle logs and navigation; neat is for the manifest on disk.

kubectl neat vs kubectl get -o yaml

Summary

Small tool. Massive quality-of-life improvement. You will pipe everything through neat within a week of installing it.