Skip to main content
Components are how sitectl models optional capabilities within a stack. Instead of treating a project as one large, all-or-nothing setup, components let each optional feature carry its own defaults, configuration rules, and operator guidance.

​
What a component does

When a plugin defines a component, sitectl can:
  • Ask about it during site creation — prompting you to enable or disable it before the first launch
  • Report its current state — sitectl component describe lists all components registered by the active context’s plugin, showing whether each one is on, off, or out of alignment with the project files
  • Apply state changes safely — sitectl set <name> <on|off> records the desired state, and sitectl converge applies the resulting file changes with a confirmation step before anything destructive happens

​
Component states

A component can be in one of two states:
StateMeaning
onThe component is active and its services, configuration, and Drupal modules are in place
offThe component is inactive; its services and configuration are removed or suppressed
Within a state, a component also carries a disposition that records more detail about how it ended up there:
DispositionMeaning
enabledExplicitly turned on by an operator
disabledExplicitly turned off by an operator
supercededReplaced by a different component or approach. This is the current CLI spelling.
distributedPlugin-specific distributed topology, such as routing ISLE IIIF traffic to an external upstream

​
Checking component state

# Show all components for the active context's plugin
sitectl component describe

# Target a specific project directory
sitectl component describe --path /path/to/project
This reports every registered component: its name, current state, and whether the live project files match what sitectl expects. A drifted status means the project files no longer match the last applied component state — usually something was changed outside of sitectl. Use --verbose to show the failed checks behind a drifted component: 
sitectl component describe --verbose
sitectl component describe --component blazegraph --verbose
When a drifted component blocks another change, sitectl prints the files and checks that failed, such as a missing Drupal config sync file or an unexpected value in docker-compose.yml.

​
Turning components on and off

# Using the top-level set command
sitectl set fcrepo off
sitectl set blazegraph on

# Using a plugin namespace when multiple plugins are involved
sitectl set isle/fcrepo off
After running sitectl set, the desired state is recorded but project files are not yet changed. Follow up with sitectl converge to apply the change.
Component changes can rewrite files and Drupal configuration sync files. Make sure you have a recent backup before enabling or disabling components on a production site.

​
Applying changes with converge

# Preview what would change
sitectl converge --report

# Apply changes interactively
sitectl converge

# Apply changes for a single component
sitectl converge --component fcrepo
converge compares each component’s expected configuration against the project files on disk and repairs any differences. Use --report to review changes before applying them.

​
The create flow

When you run sitectl create isle, sitectl asks you about each component that has a meaningful architectural choice — like whether to include Fedora or Blazegraph. You can answer interactively or pass flags to skip the prompts. Your choices are applied to the project before the first launch.

​
Current ISLE components

Fedora Commons repository. Controls whether Fedora services, volumes, Alpaca indexing, Drupal Fedora config, and filesystem URI rewrites are included in the stack. Use enabled for the standard Fedora-backed Islandora repository or superceded with --isle-file-system-uri when another filesystem backend replaces Fedora. See fcrepo.
Blazegraph triple store. Controls the Blazegraph service, volume, Alpaca triplestore indexing, Drupal triplestore namespace, and managed triplestore actions. Use enabled for standard RDF/SPARQL indexing or disabled for stacks that do not use linked data queries. See Blazegraph.
Controls which IIIF image server implementation the stack uses. cantaloupe keeps the Cantaloupe service and /cantaloupe/iiif/2 Drupal URL. triplet replaces it with Triplet, routes /iiif, writes Triplet config, and updates Drupal to use /iiif/3. See IIIF components.
Controls whether the selected IIIF implementation runs in the local Compose stack or behind an external upstream. The default disabled disposition means local. Use distributed with --iiif-upstream-url when Drupal should point to an external Cantaloupe or Triplet service and the base stack should remove the selected local IIIF service. sitectl keeps a local override in docker-compose.dev.yml. See IIIF components.
Controls whether fits, crayfits, homarus, houdini, hypercube, and mergepdf run in the base Compose stack or use the managed LibOps microservices. Use distributed to remove the service from docker-compose.yml, update Alpaca’s service URL where applicable, and keep a local development override in docker-compose.dev.yml. Use enabled to restore the service locally. See derivative microservices.
Shared ingress behavior such as TLS mode, certificate inputs, ingress status, and bot mitigation is documented with Traefik service commands. Application plugins may still provide app-specific route wiring, but the reusable command surface belongs to core sitectl.

​
What’s planned

The component model is designed to grow. Planned additions include:
  • Memcached / Redis — add caching layers to the Drupal stack
  • Load balancer support — configure ISLE to run behind an upstream reverse proxy
See the developer component guide for how components are defined and what each field in the definition struct means.