# atmos kubernetes validate

Catch broken manifests before they reach the cluster. `validate` renders the
component and checks the resulting Kubernetes objects — confirming every object
has a valid `apiVersion`/`kind`, a present and well-formed `metadata.name`, and
a resolvable group/version/kind. With `--server`, it additionally validates the
objects against the live cluster using a server-side dry-run apply.

**Configure Kubernetes Components**

`validate` uses the same stack inputs as the rest of the lifecycle:
`provider`, `paths`, `manifests`, `vars`, `env`, Auth, hooks, and
dependencies.

Stack Configuration

[Read more](/stacks/components/kubernetes)

## Usage

```shell
atmos kubernetes validate <component> --stack <stack> [options]
atmos kubernetes validate --affected --base origin/main
```

`validate` resolves the component stack configuration, renders the final
Kubernetes manifests (the same way [`render`](/cli/commands/kubernetes/render)
does), and then validates the rendered objects.

By default, validation is **offline** — it does not contact the Kubernetes API
server. It reports every invalid object in a single run (it does not stop at the
first failure) and exits non-zero if any object fails.

When every object fails fast matters most: the same offline structural checks
run automatically before [`apply`](/cli/commands/kubernetes/apply) and
[`deploy`](/cli/commands/kubernetes/deploy), so a malformed manifest is rejected
before anything is sent to the cluster or delivered to a provision target.

## Examples

Validate a single component offline:

```shell
atmos kubernetes validate argocd -s plat-ue2-dev
```

Validate against the live cluster with a server-side dry-run apply:

```shell
atmos kubernetes validate argocd -s plat-ue2-dev --server
```

Validate all Kubernetes components in dependency order:

```shell
atmos kubernetes validate --all -s plat-ue2-dev
```

Validate affected Kubernetes components:

```shell
atmos kubernetes validate --affected --base origin/main
```

## What is validated

Offline (default):

- `apiVersion` and `kind` are present (also enforced during rendering).
- `metadata.name` is present and is a valid DNS-1123 subdomain.
- The object resolves to a non-empty group/version/kind.

With `--server`:

- Each object is sent to the Kubernetes API server as a server-side dry-run
  apply, surfacing schema errors (unknown or mistyped fields) and missing
  Custom Resource Definitions authoritatively. Requires a reachable cluster and
  a configured kubeconfig.

## Flags

- **`--stack`, `-s` (required)**
  Atmos stack.
- **`--server` (optional)**

  Also validate the rendered manifests against the live cluster using a
  server-side dry-run apply. Requires a reachable cluster and kubeconfig.
- **`--all` (optional)**
  Validate all Kubernetes components in dependency order.
- **`--affected` (optional)**
  Validate affected Kubernetes components and their dependencies.
- **`--base` (optional)**
  Base branch, tag, or commit used when selecting affected components.
- **`--include-dependents` (optional)**
  With 
  `--affected`
  , include dependent Kubernetes components.