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.

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.

All articles

AI Coding Agents

Infrastructure

How to validate Kubernetes manifests before rollout

September 26, 2026 - 4 minute read

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 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 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.

Run validation in CI. Droid Exec 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 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 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.

Talk with Factory

Discuss your team’s software development, privacy, or deployment requirements.