# kubectl apply: Command Reference for CI/CD

> Reference for kubectl apply: declarative create-or-update from manifests, server-side apply, dry-run validation, and a CI example for your pipeline.

Source: https://latchkey.dev/learn/command-reference/kubectl-apply-command-cli-reference  
Updated: 2026-06-26

Reconcile cluster state to your manifests in one declarative command.

kubectl apply is the workhorse deploy command in CI: it creates what is missing and patches what changed, computing the diff for you. This reference lists the flags you use most and a CI example that validates before it writes.

## Common flags and usage

- -f, --filename: manifest file, directory, or URL (repeatable)
- -k, --kustomize: apply a kustomize directory
- --server-side: server-side apply with field-manager tracking (modern CI default)
- --dry-run=server: validate against the live API without writing
- --prune -l <selector>: delete objects in the selector set no longer in the manifests
- --force-conflicts: take ownership on a server-side apply field conflict

## Example

```shell
kubectl apply -f k8s/ --dry-run=server   # validate against the cluster
kubectl apply -f k8s/ --server-side \
  --field-manager=ci-pipeline
kubectl rollout status deploy/web --timeout=120s
```

## In CI

Run apply with --dry-run=server first so a malformed or schema-invalid manifest fails the job before any change reaches the cluster. Use --server-side with a stable --field-manager so ownership is attributed to the pipeline, then gate the real apply on kubectl rollout status. On Latchkey managed runners this whole sequence runs on an ephemeral runner with no shared kubeconfig state between jobs.

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

### kubectl apply: Command Reference for CI/CD?

kubectl apply is the workhorse deploy command in CI: it creates what is missing and patches what changed, computing the diff for you. This reference lists the flags you use most and a CI example that validates before it writes.

### In CI?

Run apply with --dry-run=server first so a malformed or schema-invalid manifest fails the job before any change reaches the cluster. Use --server-side with a stable --field-manager so ownership is attributed to the pipeline, then gate the real apply on kubectl rollout status.

---

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