> ## 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.

# lifecycle

> Build, start, stop, inspect, and roll out an Omeka Classic stack with core sitectl commands.

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>;

Omeka Classic does not define its own lifecycle commands. Like every application
plugin, an Omeka Classic stack is built, started, stopped, inspected, and rolled out
with the **core** `sitectl` commands, which operate on whichever context is active:

```bash theme={null}
sitectl create omeka-classic   # scaffold the stack and its context
sitectl compose build          # build images
sitectl compose up -d          # start the stack
sitectl compose ps             # service status
sitectl compose logs -f        # follow logs
sitectl compose down           # stop the stack
sitectl deploy                 # pull updates and restart (rollout)
```

The downstream Dockerfile builds from `libops/omeka-classic:3.2.1-php84`; that published image already contains the matching Omeka Classic release. Before changing that app version, back up MariaDB and the user-owned `omeka-classic-files` named volume:

```bash theme={null}
mkdir -p backups
sitectl mariadb backup omeka_classic --gzip --output backups/omeka-classic-pre-upgrade.sql.gz
```

Archive and test restoration of the files volume with your Docker-volume backup procedure; the database dump does not contain uploaded files.

Omeka Classic provides its supported database upgrade through the web administration flow, not a supported CLI command. `sitectl deploy` starts only `omeka-classic` and its required dependencies, waits with bounded probes, and inspects the public maintenance marker without starting public Traefik. A current database proceeds to the final bounded full-stack start. A required upgrade 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 upgrade through the admin front controller:

```bash theme={null}
sitectl port-forward 8080:omeka-classic:80
```

Stop the forward with `Ctrl+C`, then resume without changing the reviewed checkout or pulling different images:

```bash theme={null}
sitectl deploy --skip-git --no-pull
sitectl healthcheck
```

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 plugins and themes; the core schema gate cannot attest to extension-specific upgrade work.

The Omeka Classic plugin does not register the generic `dev-mode` component. A whole-directory plugins 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 plugin/theme directory in a local override.

`sitectl omeka-classic ...` is reserved for Omeka Classic-specific operations, including the
[API helpers](/plugins/omeka-classic/api) and [resource shortcuts](/plugins/omeka-classic/resources).
General <Compose /> lifecycle stays in the core CLI so the same operational contract
applies to every stack.

See [`sitectl create`](/commands/create), [`sitectl compose`](/commands/compose), and
[`sitectl deploy`](/commands/deploy) for the full lifecycle reference.