Skip to content

Operator guide

This guide is the red line through the repository. It explains the normal lifecycle of a MISP deployment managed by MISP Docker Lifecycle Manager and points to detailed docs when you need them.

Use it after Getting started when you need to operate an installed deployment day to day.

Day-2 task map

I need to… Use this section Deep dive
Confirm what is running Check status and versions Monitoring, Compatibility
Verify login/readiness Verify readiness before using the UI Troubleshooting, Security
Update safely Update safely Upgrade path
Take a backup Back up before risky changes Backup, restore, and rollback
Restore or roll back Restore and recover Backup, restore, and rollback
Remove a managed install Reset or remove a managed deployment Shell scripts reference
Investigate failures Troubleshoot with a path Troubleshooting

1. Understand the model

MISP Docker Lifecycle Manager does not replace MISP and does not fork MISP/misp-docker.

It manages a normal official MISP Docker checkout by adding:

  • generated .env values and secrets;
  • generated Compose overrides;
  • install, update, backup, restore, status, doctor, login-check, and reset helpers;
  • compatibility and validation documentation;
  • operator guidance around safe lifecycle actions.

The deployment remains no-lock-in: if the manager repository is removed after installation, the install directory remains a normal official MISP/misp-docker checkout that can be operated manually with Docker Compose.

Read more: Architecture, Support matrix.

2. Decide whether this fits your use case

The intended scope is a single-server Docker deployment managed by a human operator.

Good fit:

  • one host;
  • official MISP Docker components;
  • Docker Compose lifecycle;
  • reverse proxy in front of MISP;
  • backup-first updates;
  • restore-based recovery.

Not the current scope:

  • Kubernetes;
  • high availability;
  • multi-node orchestration;
  • custom MISP image builds;
  • replacing the official MISP Docker project.

Read more: Support matrix.

3. Prepare the host

For Rocky Linux hosts, use:

sudo ./lifecycle/prepare-host-rocky.sh

The helper is intentionally conservative about Docker group membership because Docker group access is effectively root-equivalent. Use sudo unless you intentionally accept that trade-off. It rejects hosts outside the supported Rocky-compatible Linux and x86_64 matrix before package changes; --allow-unsupported-host is an expert testing override only.

Read more: Getting started, Security.

4. Install the deployment

The normal production-oriented path is reverse-proxy mode:

sudo ./lifecycle/install.sh \
  --install-dir /opt/misp-docker \
  --upstream-ref master \
  --base-url https://misp.example.com \
  --admin-email admin@example.com \
  --admin-org ExampleOrg \
  --timezone Europe/Zurich \
  --exposure reverse-proxy

The manager clones official upstream MISP Docker into the install directory, generates local configuration, pins component image tags, starts the stack, waits for readiness, runs database updates, and verifies the result. The base URL, administrator email, and organization are required and validated before the install directory is changed. With --no-start, the manager prepares and validates configuration but reports that startup and runtime checks were skipped.

Read more: Getting started, Production deployment guide.

5. Verify readiness before using the UI

Run these checks after install, update, restore, or any change that can affect login:

sudo ./lifecycle/doctor.sh --install-dir /opt/misp-docker
sudo ./lifecycle/login-check.sh --install-dir /opt/misp-docker
sudo ./lifecycle/admin-credentials.sh --install-dir /opt/misp-docker

The login check is designed not to print the password. The credential helper hides the password unless --show-password is explicitly requested.

Read more: Troubleshooting, Security.

6. Check status and versions

Use status and version checks before updates, before troubleshooting handoff, and when comparing local runtime state with published compatibility evidence:

sudo ./lifecycle/status.sh --install-dir /opt/misp-docker
./lifecycle/get-current-misp-versions.sh --install-dir /opt/misp-docker

The status command reports the managed deployment state. The version helper shows what is running locally and what official upstream currently declares. For integration with Zabbix, Checkmk, Nagios/Icinga, Prometheus-style text output, or automation, use the monitoring contract.

Read more: Monitoring, Upgrade path, Compatibility.

7. Update safely

The update helper is backup-first:

sudo ./lifecycle/update.sh --install-dir /opt/misp-docker

For rollback drills, keep the pre-update backup outside the deployment directory:

sudo ./lifecycle/update.sh \
  --install-dir /opt/misp-docker \
  --backup-root /var/backups/misp

After update, verify again with doctor.sh and login-check.sh.

Read more: Upgrade path, Backup, restore, and rollback.

8. Back up before risky changes

Create a backup before updates, reset attempts, host maintenance, or configuration changes:

sudo ./lifecycle/backup.sh \
  --install-dir /opt/misp-docker \
  --backup-root /var/backups/misp

Use a protected backup root outside the deployment directory so reset and failed-update recovery cannot remove the backup with the deployment. The backup helper briefly stops only running application services, captures the database and host data consistently, validates checksums and archive structure, then restarts those services.

Backups include:

  • database dump;
  • host data;
  • generated deployment configuration;
  • checksums.

Store backups somewhere protected. They may contain sensitive operational data and secrets.

Read more: Backup, restore, and rollback, Security.

9. Restore and recover

Restore from a backup directory:

sudo ./lifecycle/restore.sh \
  --backup-dir /path/to/misp-backup-RANDOM_SUFFIX \
  --install-dir /opt/misp-docker \
  --yes

Restore is intentionally explicit because it can overwrite deployment state. It verifies checksums, restores generated config and host data, imports the database, starts the stack, waits for readiness, and runs verification.

The same restore workflow is used for restore-based rollback after a failed update.

Read more: Backup, restore, and rollback.

10. Reset or remove a managed deployment

Start with a dry run:

sudo ./lifecycle/reset-installation.sh --install-dir /opt/misp-docker

Destructive reset requires explicit confirmation and checks for lifecycle-manager markers. Docker Engine itself is not removed.

Read more: Shell scripts reference, Security.

11. Check validation evidence

Compatibility is not claimed generically. It is tracked as:

manager release/ref × official MISP Docker component set = status

Read the compatibility docs before assuming a release has been validated for a given MISP component set. Keep the release channel distinction in mind: latest published and latest validated-compatible can differ.

Read more: Compatibility, Validation matrix, Production readiness.

12. Troubleshoot with a path

Start with the local state commands, then move to the troubleshooting guide with those results:

sudo ./lifecycle/doctor.sh --install-dir /opt/misp-docker
sudo ./lifecycle/login-check.sh --install-dir /opt/misp-docker
sudo ./lifecycle/status.sh --install-dir /opt/misp-docker

Then follow Troubleshooting. Common categories are invalid URLs, reverse-proxy mismatch, not-yet-ready login, component tag problems, Docker/host issues, and credential handling mistakes.