Skip to main content
The recommended command is sitectl validate, which runs core checks and ISLE-specific checks together in a single report. The sitectl isle validate command is still available for running ISLE checks in isolation.
Run validate before starting a stack for the first time, after changing context wiring, or when diagnosing unexpected behaviour. It catches common misconfigurations before they become runtime failures.

Reference

Top-level command (recommended): Validate the active context’s configuration and project layout. Core checks include: required context fields, compose project presence, context file accessibility, override symlink, and Docker socket access. If the active context’s plugin registers a validate handler, plugin-specific checks (e.g. Drupal rootfs path, component state consistency) are also run and merged into the report. All flags not consumed by sitectl itself are forwarded to the plugin’s validate handler, allowing plugin-specific flags such as --drupal-rootfs. Exits non-zero if any check fails. Examples: sitectl validate sitectl validate --format table sitectl validate --drupal-rootfs drupal/rootfs
sitectl validate [flags]
ISLE plugin command (standalone): Validate the active context’s configuration and project layout. Checks include: context wiring, required Traefik configuration, Drupal rootfs path, and component state consistency. Exits non-zero if any check fails.
sitectl isle validate
FlagDefaultDescription
--drupal-rootfsdrupal/rootfs/var/www/drupalDrupal rootfs relative to --path. Used to resolve composer.json and config/sync
--formatsectionReport output format: section, table, json, or yaml
--pathPath to the project directory. Defaults to the active context project directory.

ISLE checks

When the active context uses the ISLE plugin, sitectl validate automatically includes:
  • drupal-rootfs — confirms the Drupal web root exists at the expected path
  • traefik-cantaloupe-config — confirms the required Traefik config file is present
  • component:* — reports each component’s drift state (ok, drifted, warning)

When to run it

  • After sitectl config set-context to verify the new context is wired correctly.
  • Before deploying to production to confirm component state is consistent.
  • When sitectl compose up fails with an unexpected error — validate often points to the root cause.

See also