Skip to main content

Validate Configurations

Before you deploy, you'll catch mistakes early. Atmos validates two things: that your stack manifests are well-formed (against a schema it ships with), and that your component configuration obeys rules you define — with JSON Schema for shape and OPA policies for business logic.

By the end of this step you'll lint every stack with one command and block an invalid s3-bucket from ever being provisioned.

Validate stack manifests​

Atmos ships the manifest JSON Schema embedded, so linting every stack is a single command with nothing to configure:

atmos validate stacks

This checks that your manifests use valid sections and types. It's the fastest way to catch a typo'd key or a malformed import before it reaches Terraform.

No schema to download

Older guides had you copy a atmos-manifest.json into the repo and point schemas.atmos.manifest (or ATMOS_SCHEMAS_ATMOS_MANIFEST) at it. That's no longer needed — Atmos validates against its built-in schema by default. You only configure schemas when you bring your own component schemas, below.

Validate component configuration​

Beyond well-formed manifests, you can enforce rules on a component's actual configuration. Tell Atmos where your schemas live by adding a schemas section to atmos.yaml:

atmos.yaml
schemas:
  jsonschema:
    base_path: "stacks/schemas/jsonschema"
  opa:
    base_path: "stacks/schemas/opa"

Then wire validation into a component's settings.validation. Here s3-bucket is checked by both a JSON Schema (shape) and an OPA policy (business rules):

stacks/catalog/s3-bucket/defaults.yaml
components:
  terraform:
    s3-bucket:
      settings:
        validation:
          validate-s3-bucket-with-jsonschema:
            schema_type: jsonschema
            schema_path: "s3-bucket/validate-s3-bucket-component.json"
            description: Validate 's3-bucket' variables using JSON Schema
          check-s3-bucket-with-opa-policy:
            schema_type: opa
            schema_path: "s3-bucket/validate-s3-bucket-component.rego"
            module_paths:
              - "catalog/constants"
            description: Check 's3-bucket' configuration using OPA policy
            timeout: 10

JSON Schema — validate shape​

The JSON Schema checks the shape of the variables: the bucket name must be a lowercase slug of 2–40 characters, and versioning_enabled must be a boolean.

stacks/schemas/jsonschema/s3-bucket/validate-s3-bucket-component.json
{
  "$id": "s3-bucket-component",
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "vars": {
      "type": "object",
      "properties": {
        "name": { "type": "string", "minLength": 2, "maxLength": 40, "pattern": "^[a-z0-9-]+$" },
        "versioning_enabled": { "type": "boolean" }
      },
      "required": ["name", "versioning_enabled"]
    }
  }
}

OPA — enforce business rules​

The OPA policy encodes rules that span variables — most importantly, in prod, S3 buckets must have versioning enabled. Atmos reads the policy's errors array; any message there fails validation and the component won't provision.

stacks/schemas/opa/s3-bucket/validate-s3-bucket-component.rego
package atmos

# In production, S3 buckets must have versioning enabled.
errors[message] {
    input.vars.stage == "prod"
    input.vars.versioning_enabled != true
    message := "In 'prod', S3 buckets must have versioning enabled. Set 'versioning_enabled' to 'true'"
}

Validate a single component in a stack:

atmos validate component s3-bucket -s plat-ue2-prod
Notice how the rule is environment-aware

The same s3-bucket config passes in dev and fails in prod if versioning is off — because the OPA policy reads input.vars.stage. Validation runs against the fully resolved component config, so policies can reason about the real, merged values. See Custom Policy Validation for more.

Next: everything's in place — bring the whole backend up → Deploy Everything →