Skip to main content
Omeka S does not define its own lifecycle commands. Like every application plugin, an Omeka S stack is built, started, stopped, inspected, and rolled out with the core sitectl commands, which operate on whichever context is active:
The downstream Dockerfile builds from libops/omeka-s:4.2.1-php84; that published image already contains the matching Omeka S release. Before changing that app version, back up MariaDB and the user-owned omeka-s-files named volume:
Archive and test restoration of the files volume with your Docker-volume backup procedure; the database dump does not contain uploaded files. Omeka S provides its supported database migration through the web administration flow, not a supported CLI command. sitectl deploy starts only omeka-s and its required dependencies, waits with bounded probes, and inspects /admin without starting public Traefik. A current database proceeds to the final bounded full-stack start. A required migration prints ACTION REQUIRED and exits nonzero while the internal application remains available and public ingress remains stopped. In another terminal, create a loopback-only forward, open http://localhost:8080/admin, and complete the migration:
Stop the forward with Ctrl+C, then resume without changing the reviewed checkout or pulling different images:
Reuse the same --context NAME on both commands when the original deploy selected a non-active context. Finish with an application smoke test and verify custom modules and themes; the core schema gate cannot attest to extension-specific upgrade work. The Omeka S plugin does not register the generic dev-mode component. A whole-directory modules or themes mount would hide extensions bundled in the versioned base image. Put custom extensions in the tracked downstream build context, or mount only an explicitly named custom module/theme directory in a local override. sitectl omeka-s ... is reserved for Omeka S-specific operations, including the API helpers and resource shortcuts. General lifecycle stays in the core CLI so the same operational contract applies to every stack. See sitectl create, sitectl compose, and sitectl deploy for the full lifecycle reference.