# How to validate Kubernetes manifests before rollout
> Kubernetes manifest validation should render the final objects, run server-side dry run against a matching API server, check field ownership with server-side apply, and keep rollout with reviewers. A practical gate for coding agent changes on Factory.
URL: https://factory.com/articles/kubernetes-manifest-validation-coding-agents
Published: 2026-09-26
Updated: 2026-10-23
To validate Kubernetes manifests before rollout, render the final objects from Helm or Kustomize, submit them with server-side dry run to a non-production API server that matches the target version and admission policies, and check field ownership with a server-side apply dry run. YAML that parses locally can still be rejected or changed by the cluster.
Kubernetes manifest validation has to cover more than YAML syntax. A coding agent can produce a well-formed Deployment that names an unavailable API version, conflicts with an admission policy, or takes ownership of fields managed by another controller. The useful review target is the object the cluster would accept, not just the file in the pull request.
The [Kubernetes API concepts](https://kubernetes.io/docs/reference/using-api/api-concepts/) describe server-side dry run as normal admission processing without persistence. That makes it a stronger validation step than a local parser when a change is meant for a known cluster.
## Scope Kubernetes manifest validation
Give the agent the manifest paths, target Kubernetes version, namespaces, overlays, and policy sources. Include the exact render command for Helm, Kustomize, or another generator. Reviewing templates without their rendered output misses values, patches, and environment-specific names.
Keep the task bounded to the reported deployment problem. The agent may correct a selector, resource request, probe, or deprecated API version. It should not reorganize unrelated charts or normalize every manifest in the repository. A focused diff lets a reviewer connect each field change to a requirement.
## Run Kubernetes manifest validation with the API server
Render the final manifests, then submit them with server-side dry run against a non-production control plane that matches the target version and admission configuration. Capture validation errors as artifacts. This checks schema handling, defaults, mutating admission, and validating admission without storing the object.
Follow that with server-side apply dry run when field ownership matters. Kubernetes [Server-Side Apply](https://kubernetes.io/docs/reference/using-api/server-side-apply/) tracks which manager owns each field. A conflict can reveal that the proposed change would overwrite a value maintained by an operator or another deployment system.
Dry run cannot prove that an image starts, a dependency is reachable, or a rollout is safe under load. Run policy checks, image verification, and workload tests as separate gates. Keep each result visible so a passing schema check does not hide a failed runtime assumption.
Each layer answers one question and leaves the next one open. The table summarizes what each check covers.
| Check | What it proves | What it misses |
| --- | --- | --- |
| Local YAML parse | The file is well formed | API versions, defaults, admission policy |
| Rendered diff | The final object after Helm or Kustomize | Whether the cluster accepts it |
| Server-side dry run | The API server accepts the object after admission | Whether the image starts |
| Server-side apply dry run | No field ownership conflicts with other managers | Runtime behavior |
| Policy and image checks | Organization rules and image verification | Behavior under load |
| Workload tests | The service starts and serves traffic | Production timing and scale |
## Keep Kubernetes manifest validation evidence reviewable
The pull request should include the render command, target cluster version, changed object names, server-side validation result, and any ownership conflicts. Show the diff between the previously rendered object and the proposed object. Generated output should be reproducible from files in the branch.
Require a human decision for rollout timing, namespace scope, and production credentials. The coding agent can prepare evidence and fix a bounded defect. The deployment controller and reviewers should decide when accepted configuration reaches a live cluster.
## How Factory fits a manifest validation gate
Factory is a platform for running a software factory, where agents called Droids take work from a signal to a reviewed pull request. For Kubernetes changes, Factory runs the validation and review steps while the pipeline keeps cluster credentials and people keep the rollout decision.
Pull request
manifest or chart change"]
B["Render
Helm or Kustomize, pinned command"]
C["Droid Exec in CI
server-side dry runs, pipeline-owned credentials"]
D["Code review
review-guidelines skill for probes, limits, selectors"]
E["Human decision
rollout timing and namespace"]
A --> B --> C --> D --> E
`}
/>
**Run validation in CI.** [Droid Exec](https://docs.factory.com/droid-exec/overview) runs a scoped repository task as one non-interactive pass and is read-only unless you raise its autonomy level. The pipeline selects the cluster and provides credentials, so the task never needs broad Kubernetes configuration access.
**Review against your conventions.** Factory's [automated code review](https://docs.factory.com/software-factory/code-review-ci) runs on pull request events, skips drafts, and posts inline comments. A `review-guidelines` skill at `.factory/skills/review-guidelines/SKILL.md` can direct it to check selectors, probes, resource limits, and security contexts.
**Limit what the agent can run.** Command rules in [Agent Safety & Controls](https://docs.factory.com/enterprise/llm-safety-and-agent-controls) can allow, ask about, or block matching commands, such as a `kubectl apply` without a dry-run flag. The docs note that command rules are not a sandbox, so keep cluster credentials scoped as well.
## Frequently asked questions
### What is Kubernetes manifest validation?
Kubernetes manifest validation checks that the objects in a change will be accepted by the target cluster and behave as intended. It goes beyond YAML syntax to cover API versions, admission policies, defaults, and field ownership.
### What does server-side dry run check?
Server-side dry run sends the object through normal admission processing on the API server without persisting it. It catches schema errors, defaults, and mutating and validating admission results.
### When should you use server-side apply dry run?
Use it when field ownership matters. Server-side apply tracks which manager owns each field, so a conflict shows that the change would overwrite a value maintained by an operator or another deployment system.
### What can dry run not prove?
Dry run cannot prove that an image starts, a dependency is reachable, or a rollout is safe under load. Run policy checks, image verification, and workload tests as separate gates.
### How does Factory help validate Kubernetes changes?
Droid Exec can run render and dry-run steps in CI, and Factory code review checks the pull request with repository-specific guidelines. Reviewers and the deployment controller still decide when a change reaches a live cluster.
## Further reading
- [Infrastructure as code changes with agents](https://factory.com/articles/infrastructure-as-code-agent-review)
- [Configuration drift](https://factory.com/articles/coding-agent-configuration-drift)
- [Container image hardening](https://factory.com/articles/container-image-hardening-coding-agents)
- [Least privilege](https://factory.com/articles/least-privilege-coding-agents)
- [Kubernetes Server-Side Apply](https://kubernetes.io/docs/reference/using-api/server-side-apply/)