Validation & Schemas | Ghostable CLI 3.x | Ghostable Menu Validation & Schemas Schema files ------------ Global rules live in `.ghostable/schema.yaml`. Rules for one environment live in `.ghostable/schemas/.yaml`. Both are plaintext, repository-visible contracts and must not include secret values. Schema format ------------- ``` APP_ENV: - required - in:local,staging,production APP_URL: - required - url - starts_with:https:// QUEUE_CONNECTION: - nullable - string SESSION_LIFETIME: - required - integer - min:1 - max:1440 ``` Each top-level key maps to a list of rules. Rules with arguments use `name:argument`. The presence of `nullable` skips other rules for a missing or empty value regardless of where it appears in the list; `required` still wins when both are present. Supported rules --------------- `required` The key must exist and have a non-empty value. `nullable` Other rules are skipped when the value is missing or empty. `string` Accepts the env value as a string. `integer / numeric` Requires an integer or floating-point-compatible numeric value. `boolean` Accepts true, false, 1, 0, yes, or no, case-insensitively. `email / url` Requires a valid email address or absolute URL. `starts_with / ends_with` Requires the declared prefix or suffix. `regex` Requires a match against a Go RE2-compatible expression. Use the schema command to avoid hand-escaping YAML. `in` Requires one of a comma-separated set of exact values. `min / max` Compares parseable numeric values numerically and other values by UTF-8 byte length. `different_from` Compares the same key against stored values in another environment. It passes when that environment has no matching key. ``` REGION: - required - 'regex:^[A-Z]{2}$' API_KEY: - required - min:32 - different_from:staging ``` In this example, `REGION=US` passes while `REGION=us` fails. `API_KEY` must be at least 32 bytes and must not equal the stored `API_KEY` in staging. Environment-specific rules -------------------------- Environment rules are appended to global rules for the same key. This makes it possible to keep a shared contract while adding production requirements: ``` # .ghostable/schemas/production.yaml APP_KEY: - required - different_from:staging APP_DEBUG: - required - in:false,0 ``` Manage schemas -------------- Schema commands Copy ``` $ ghostable schema rule add --key APP_URL --rule required $ ghostable schema rule add --key APP_URL --rule url $ ghostable schema rule update --key APP_URL --old-rule url --new-rule starts_with:https:// $ ghostable schema rule remove --key APP_URL --rule starts_with:https:// $ ghostable schema key rename --old-key OLD_API_URL --new-key API_URL ``` Pass `--file .ghostable/schemas/production.yaml` to target an environment-specific schema. Run validation -------------- Validate values Copy ``` $ ghostable validate --env production $ ghostable validate --env staging --file .env.staging $ ghostable validate --env production --json ``` Without `--file`, validation reads stored encrypted values. With `--file`, it validates that local file against the selected environment's merged rules. A warning is emitted when no schema rules exist. A `different_from` rule still reads the referenced environment even during file validation. If that environment is protected, the local device must satisfy user-presence verification; automation needs a credential with reader access to both environments. On this page [ ![Ghostable](https://ghostable.dev/images/logo-dark.svg) ![Ghostable](https://ghostable.dev/images/logo-light.svg) ](https://ghostable.dev) CLI 3.x [ CLI 3.x ](https://ghostable.dev/docs/3.x) [ Desktop ](https://ghostable.dev/docs/desktop) CLI 3.x introduction Documentation local first no login encrypted repository plaintext hosted service Installation Documentation brew homebrew npm npx linux windows PATH version update Start a new project Getting Started setup seed dotenv owner initialize Adopt an existing project Getting Started existing env import authoritative source adopt Onboard a team member Getting Started join request approve roles offboarding pull request Repository and storage Core Concepts .ghostable git conflict merge worktree private identity metadata Environments Core Concepts protected production preview staging push sync pull replace run mask-output Variables and promotions Core Concepts var promote copy context annotation key Access and devices Core Concepts identity reader writer grantor owner revoke rotate leave delete Daily development workflow Workflows pull diff validate review clean daily Review and secret scanning Workflows scan sarif github suppress secrets drift Hygiene and rotation Workflows rotation stale unused suppression environment key Automation credentials Automation & CI GHOSTABLE\_CI\_TOKEN ci deploy credential powershell revoke replace Continuous integration Automation & CI GitHub Actions fork pull request JSON stdout stderr exit codes mask-output Deployments Automation & CI Forge Vapor Cloud provider CLI dry-run preserve remote keys temporary files Validation Reference schema required nullable regex min max different\_from Command reference Reference --help --json NO\_COLOR flags aliases exit code automation Configuration Reference ghostable.yaml activity mode auditEnvironments scan ignores deployTarget dotenv syntax Security Reference cryptography XChaCha20 Poly1305 HKDF user presence threat model Backups & Offline Reference recovery offline restore clone key identity Agent integration Reference AGENTS.md capabilities allowlist coding agent Troubleshooting Reference no project found revoked identity stale policy user presence invalid CI token provider CLI git conflict diagnostics Ghostable Desktop overview Desktop Installation Desktop Projects and setup Desktop Interface tour Desktop Environments and variables Desktop Local environment files Desktop Validation and review Desktop Activity Desktop Access and automation Desktop Project settings Desktop Application settings Desktop Licensing and updates Desktop Security and storage Desktop Troubleshooting Desktop No results found