> ## Documentation Index
> Fetch the complete documentation index at: https://sitectl.libops.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Application plugins

> How sitectl uses plugins so you install only the application workflows for the apps you actually run.

export const Compose = () => <Tooltip headline="Compose" tip={<>
        Docker Compose is Docker's tool for defining and running multi-container applications.{" "}
        <a href="https://docs.docker.com/compose/">https://docs.docker.com/compose/</a>.
      </>}>
    <>
      <Icon icon="docker" />
      {" "}
      Compose
    </>
  </Tooltip>;

Core `sitectl` knows how to drive any <Compose /> stack: building, starting, stopping,
deploying, and inspecting services, plus [shared service commands](/plugins/core-services)
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.

```bash theme={null}
# 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`](/commands/compose),
[`sitectl deploy`](/commands/deploy), [`sitectl create`](/commands/create)), so every
stack shares the same lifecycle commands regardless of which application plugin is
installed. See [Plugins](/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](/contributing/compose-reconcile) 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

<CardGroup cols={2}>
  <Card title="Drupal" icon="square-d" href="/plugins/drupal">
    Drupal-oriented workflows: drush execution, user login links, and database and config sync between environments.
  </Card>

  <Card title="Islandora" icon="layer-group" href="/plugins/isle">
    Islandora workflows: guided site creation, component management, Fedora and Blazegraph sync, and migration utilities. Includes the Drupal plugin.
  </Card>

  <Card title="WordPress" icon="globe" href="/plugins/wordpress">
    WordPress workflows: template creation, WP-CLI, Composer, plugin/theme maintenance, cache, and database helpers.
  </Card>

  <Card title="OJS" icon="book-open" href="/plugins/ojs">
    Open Journal Systems workflows: template creation, OJS PHP tools, PKP tools, scheduled tasks, jobs, and import/export helpers.
  </Card>

  <Card title="Omeka Classic" icon="landmark" href="/plugins/omeka-classic">
    Omeka Classic workflows: template creation and REST API helpers for collection, item, file, tag, user, and metadata operations.
  </Card>

  <Card title="Omeka S" icon="boxes-stacked" href="/plugins/omeka-s">
    Omeka S workflows: template creation and REST API helpers for resources, media, sites, modules, and vocabularies.
  </Card>

  <Card title="ArchivesSpace" icon="archive" href="/plugins/archivesspace">
    ArchivesSpace workflows: template creation, API helpers, search, job inspection, diagnostics, and container script wrappers.
  </Card>
</CardGroup>