# 0.x config format

Which format should I use?

See Config versions for a decision guide. 1.x is recommended for new configurations. This page documents the 0.x checks: format, which is fully supported.

Moving to 1.x? Compose, don't look for a port

1.x doesn't ship a dedicated plugin for each 0.x check. Instead you reproduce a check by composing general-purpose plugins — for example, drupal-admin-user becomes command + allowed:list. The gaps matrix lists the plugin chain that reproduces each check below.

# Overview

The 0.x format is a flat YAML file with a single top-level key: checks.

checks:
  <check-type>:
    - name: Human-readable label
      severity: normal        # low | normal | high | critical
      # ... check-specific fields

The binary auto-detects the format. If checks: is the only top-level key, the 0.x runner is used. If any of connections, collect, analyse, or output are present, the 1.x runner is used instead. See Config versions for the exact rule.

# Common fields

Every check, regardless of type, supports these fields from CheckBase:

Field	Type	Default	Description
`name`	string	required	Human-readable label shown in output
`severity`	string	`normal`	`low`, `normal`, `high`, or `critical`

The --fail-severity CLI flag controls which severity level causes a non-zero exit code. Checks below that level still run and report, but do not fail the build.

# Running a 0.x config

shipshape run -f shipshape.yml

Pass --fail-severity to override the exit threshold:

shipshape run -f shipshape.yml --fail-severity high

# Checks

The following check types are available in the 0.x format. Each links to its full reference page.

# File checks

Type	What it does
`file`	Assert files matching a pattern are absent
`file:diff`	Assert a file matches a reference template

# YAML / JSON checks

Type	What it does
`yaml`	Assert key-value pairs in YAML files
`json`	Assert key-value pairs in JSON files

# Drupal checks

Type	What it does
`drush-yaml`	Assert key-value pairs in Drupal config via Drush
`drupal-file-module`	Assert modules enabled/disabled via filesystem
`drupal-db-module`	Assert modules enabled/disabled via database
`drupal-admin-user`	Assert UID 1 has only permitted roles
`drupal-db-permissions`	Assert role permissions via database
`drupal-db-user-tfa`	Assert all users have TFA configured
`drupal-user-forbidden`	Assert a specific user account does not exist
`drupal-role-permissions`	Assert required/disallowed permissions on a role
`drupal-user-role`	Assert users with a given role are on an allow-list
`drupal-tracking-code`	Assert no tracking code is present in Drupal config

# Code quality checks

Type	What it does
`phpstan`	Run PHPStan and fail on errors
`sca:application_type`	Detect disallowed application frameworks

# Infrastructure checks

Type	What it does
`docker:base_image`	Assert Docker base images are on an allow-list
`crawler`	Crawl a site and assert all pages return 200

# Multiple checks of the same type

Each check type takes a list. You can define multiple checks of the same type with different names, paths, or severity levels:

checks:
  yaml:
    - name: Update interval
      config-name: update.settings
      path: config/default
      values:
        - key: check.interval_days
          value: "7"
    - name: Cron interval
      config-name: automated_cron.settings
      path: config/default
      values:
        - key: interval
          value: "10800"

# Merging configs

The -e flag merges a second config file on top of the first. Fields in the second file override the first; list fields are appended.

shipshape run -f base.yml -e overrides.yml

This is useful for environment-specific overrides without duplicating the full config.

← Config versions 0.x to 1.x recipe catalogue →