Mounting your data drive

Mercury Core keeps durable local state — the libraries, measures, and patient data you load persist to disk and survive a restart. In a container, that only holds if you point the state directory at a mounted volume. Without one, everything you loaded disappears when the container is recreated.

Examples below use the image URI you were given:

export MERCURY_IMAGE=IMAGE_URI

The idea

Map a location that lives outside the container (a Docker named volume, or a host directory) to Mercury’s data directory inside the container. State written there survives docker compose down, image upgrades, and host reboots, and can be backed up with your normal tooling.

Docker Compose

Add a named volume and mount it at the data directory:

services:
  mercury:
    image: ${MERCURY_IMAGE:?set MERCURY_IMAGE}
    ports:
      - "8080:8080"
    volumes:
      - mercury-data:/var/lib/mercury

volumes:
  mercury-data:

`docker run`

docker run --rm \
  -p 8080:8080 \
  -v mercury-data:/var/lib/mercury \
  "$MERCURY_IMAGE"

Prefer a host directory (easier to inspect and back up) instead of a named volume:

docker run --rm \
  -p 8080:8080 \
  -v /srv/mercury/data:/var/lib/mercury \
  "$MERCURY_IMAGE"

Verify it persists

Load a library or a data bundle (see Loading data).

Recreate the container:

docker compose down && docker compose up -d

Re-run an $evaluate for the same subject — it should still resolve without reloading.

For a real deployment, always mount /var/lib/mercury. Without that mount, the container starts with an empty state after it is recreated.

Backups

Because state is a directory on a volume, back it up the way you back up any volume — snapshot the named volume, or copy the host directory while the server is stopped or quiesced.

# Example: tar a host-mounted data directory
tar czf mercury-data-$(date +%F).tar.gz -C /srv/mercury data

Next steps

Loading data: preload vs inline — what actually gets persisted.
Running the containers — where the volume fits in the stack.