Application plugins

Core sitectl knows how to drive any stack: building, starting, stopping, deploying, and inspecting services, plus shared service commands for Traefik, MariaDB, Solr, and cache services. Application plugins add the commands and guided create flows for a specific application on top of that foundation: Drupal, Islandora, WordPress, OJS, Omeka, and ArchivesSpace. You install only the plugins for the apps you work with. A plugin is just a binary named sitectl-<app> on your $PATH. Direct app helpers use the plugin namespace, while core workflows such as create, validate, healthcheck, verify, debug, set, converge, and component describe stay in the core namespace and dispatch to the active context’s plugin over RPC.

# the OJS plugin binary on your PATH unlocks these
sitectl create ojs        # scaffold an OJS stack
sitectl ojs tool upgrade  # OJS-specific helpers

General lifecycle stays in the core CLI (sitectl compose, sitectl deploy, sitectl create), so every stack shares the same lifecycle commands regardless of which application plugin is installed. See Plugins for how discovery, inclusion, and command routing work across all plugin types. Application plugins still publish create definitions and app-specific helpers. Core sitectl compose up can use those create definitions for local first-run reconcile; see Compose reconcile contract for the contributor contract. For OJS, Omeka, and ArchivesSpace, the published LibOps base-image tag names the bundled upstream application release (and may add a runtime suffix) while the downstream template image adds local customizations. Drupal, ISLE, and WordPress keep Composer-owned application dependencies in the downstream checkout, so their base-image tag selects a runtime line rather than an application version. The plugin create metadata mirrors that ownership so compose up and deploy rebuild the correct layer. Mixing a bundled application tree with a second Composer-owned copy is unsupported because neither layer would have unambiguous ownership. Tracked dependency services use tag@sha256:digest references. Local sitectl image overrides may intentionally test another tag, image, or build argument, but production updates should move the tracked tag and digest together and pass the application’s backup and migration gate. For common MariaDB-backed web apps, plugins can use the shared healthcheck runner instead of repeating route, MariaDB, and Compose dependency checks. App-specific checks still belong in the plugin, such as Solr core checks or optional Islandora microservice HTTP checks.

Choose your application

Drupal

Drupal-oriented workflows: drush execution, user login links, and database and config sync between environments.

Islandora

Islandora workflows: guided site creation, component management, Fedora and Blazegraph sync, and migration utilities. Includes the Drupal plugin.

WordPress

WordPress workflows: template creation, WP-CLI, Composer, plugin/theme maintenance, cache, and database helpers.

OJS

Open Journal Systems workflows: template creation, OJS PHP tools, PKP tools, scheduled tasks, jobs, and import/export helpers.

Omeka Classic

Omeka Classic workflows: template creation and REST API helpers for collection, item, file, tag, user, and metadata operations.

Omeka S

Omeka S workflows: template creation and REST API helpers for resources, media, sites, modules, and vocabularies.

ArchivesSpace

ArchivesSpace workflows: template creation, API helpers, search, job inspection, diagnostics, and container script wrappers.

​Choose your application