# Validation & Schema Generation

Two things belong here: checking a config without starting anything, and emitting the JSON Schema that describes every config. Both are commands, and both work on every distribution — the binary, Docker, Homebrew.

## `sovrium validate <file>`

The pre-deploy gate.

```bash
sovrium validate app.yaml
```

Prints `Valid configuration: <name>` and exits `0`, or the errors and exits `1`. Everything that fails exits `1`, so gating a pipeline is one line:

```bash
sovrium validate app.yaml || exit 1
```

:::callout
**One validation, three commands.** `validate`, `start` and `build` read your config through the same pipeline: the same authoring shorthands are accepted, and the same cross-field rules are enforced. A config `sovrium validate` accepts is a config `sovrium start` boots. Full behaviour — exit codes, error format, `$ref` attribution — on [Validating a Config](/en/docs/config-validation).
:::

## Validating from inside a config

To check a config **from a running app** — a webhook that accepts a submitted config, a scheduled audit of a config in storage — use the `data:validate-config` automation action. It runs the same decoder `sovrium validate` runs, with no side effects and no boot.

```yaml
automations:
  - name: check-submitted-config
    trigger:
      type: webhook
      method: POST
    actions:
      - name: check
        type: data
        operator: validate-config
        props:
          config: '{{trigger.body.config}}'
          format: json
```

The step exposes `{{steps.check.valid}}` and `{{steps.check.errors}}`. See [Data Actions](/en/docs/automation-data-actions) for the full operator list.

## `sovrium schema`

Print the JSON Schema (Draft-07) for the app configuration — the same document the hosted schema URLs serve.

```bash
sovrium schema
sovrium schema --output app.schema.json
```

It takes no arguments beyond the output path and reads nothing from the environment: the schema is derived from `AppSchema` itself, so the output depends only on the Sovrium version. That makes it safe to regenerate in CI and diff — a change in the file is a change in the schema, never in the machine that ran it.

A common use is pinning the schema alongside the config so editors validate against the exact version you deploy:

```bash
# Run after every Sovrium upgrade
sovrium schema --output app.schema.json
```

```yaml
# app.yaml
# yaml-language-server: $schema=./app.schema.json
name: my-app
```

## Related Pages

- [CLI Overview](/en/docs/cli) — the full command surface.
- [Validating a Config](/en/docs/config-validation) — the CLI checker in detail.
- [JSON Schema](/en/docs/json-schema) — the hosted schema URLs.
- [Editor Setup](/en/docs/json-schema-editors) — pointing VS Code or JetBrains at it.