Skip to main content

Need the environment model first?

Validation rules apply to project environments, not isolated local files.

​
How Validation Works

Ghostable validation rules live alongside your local project metadata:
Example
.ghostable/ ghostable.yaml schema.yaml schemas/ production.yaml staging.yaml
  • .ghostable/schema.yaml defines global rules.
  • .ghostable/schemas/<environment>.yaml overrides or extends rules for a specific environment.
Validation runs locally. The client loads your schema files and compares them against the variables being worked on. Plaintext values do not need to be uploaded for validation to happen.

​
Why Teams Use It

Validation catches drift before a push, export, or deployment turns into a production issue. Common checks include:
  • required keys,
  • allowed values,
  • string length limits,
  • URLs, emails, and other format rules,
  • environment-specific overrides.

​
Desktop vs CLI

  • Desktop uses the linked project folder to read schema files, edit them in the built-in Rules Editor, and run validation against project environments.
  • CLI reads the same schema files and exposes command-driven validation for scripts and CI.
Both clients rely on the same .ghostable files, so the rules stay consistent across tools.

​
Continue with Your Client

Run validation in Desktop

Use the project Validation view to inspect schema coverage, edit rules, and run checks.

Run validation in CLI

Use terminal validation for local checks and CI gates.