Plugins

Plugins extend sitectl with commands and workflows specific to the technology stack your site runs on. General Docker operations stay in the core CLI. Use sitectl compose for context-aware Docker Compose commands and sitectl port-forward for remote service tunnels. Plugins add stack-specific value on top of that foundation: create flows, application CLIs, API helpers, sync workflows, lifecycle shortcuts, migrations, and other project-specific operations.

​

How discovery works

sitectl discovers plugins by searching your $PATH for binaries named sitectl-<plugin>. When you run a direct plugin command such as sitectl drupal drush, sitectl finds sitectl-drupal on your path and delegates the subcommand to it — passing through flags and context automatically. This means installing a plugin is as simple as putting its binary on your path. No configuration needed.

​

Command routing

Plugins expose two kinds of behavior:

• Direct plugin commands use the plugin namespace, such as sitectl drupal drush, sitectl isle sync fcrepo, or sitectl wp cache flush.
• Core workflow commands stay in the core namespace and dispatch to the active context’s plugin over RPC. This includes sitectl create, sitectl validate, sitectl healthcheck, sitectl verify, sitectl debug, sitectl set, sitectl converge, and sitectl component describe.

Plugin pages document the canonical command path. Older namespace-shaped compatibility commands are not listed as separate docs pages.

​

Plugin hierarchy

Plugins can include other plugins. sitectl-isle includes sitectl-drupal because every Islandora site is also a Drupal site. Shared, self-contained services are different. Services such as Traefik, MariaDB, Solr, Valkey, and Memcached are cross-cutting enough to live in the core sitectl command namespace. Operators still use service-oriented commands such as sitectl mariadb backup, but the command comes from core rather than an included service plugin. The active context’s plugin field determines which plugin is responsible for a given site. Commands like sitectl debug, sitectl validate, sitectl healthcheck, sitectl verify, and sitectl converge use this to route plugin-specific work automatically.

​

Core service commands

Self-contained services may still run as standalone Compose projects, but their shared command surface belongs to core sitectl. Start with the Core service commands landing page when the operation is about Traefik, MariaDB, Solr, Valkey, Memcached, or another reusable service inside a stack.

​

Application plugins

​

Assigning a plugin to a context

When you create or configure a context, you specify which plugin owns it. This is stored in the context’s plugin field. Only commands from that plugin (and any plugins it includes) are valid against that context. For example, a context with plugin: isle accepts ISLE direct commands such as sitectl isle sync fcrepo and Drupal direct commands such as sitectl drupal drush, because the Islandora plugin includes Drupal. Core workflow commands such as sitectl validate and sitectl set fcrepo off dispatch to the Islandora plugin through that same context.

​

Composition matrix

First-class application plugins follow the same composition rules:

• Web applications use Traefik for ingress.
• LAMP-style applications include MariaDB by default.
• Drupal and ArchivesSpace include Solr by default because their templates ship search enabled.
• Shared service commands come from core sitectl, not from app plugin includes.
• Traefik edge features, including TLS mode and bot mitigation, are first-class core ingress operations.

Application compose projects remain standalone repositories. App plugins own app-specific workflows; core sitectl owns shared service operations and helpers.