Skip to content

Compatibility with official MISP Docker components

misp-docker-lifecycle-manager is a lifecycle wrapper around the official MISP/misp-docker project.

It does not fork, vendor, or replace MISP. The generated deployment remains a normal official MISP Docker checkout with installer-managed configuration and lifecycle helpers.

Because this project and official MISP Docker can change independently, compatibility is tracked as a pair:

misp-docker-lifecycle-manager release/ref × official MISP Docker component set = validation status

A pair is called validated compatible only after the documented validation scenarios pass.

Latest compatibility status

Manager release/ref MISP core MISP modules MISP guard Status Validated Report
main adaptation workstream v2.5.48 v3.0.10 v1.2 🟡 Pending implementation and validation — Issue #160
v1.4.1 release tag v2.5.45 v3.0.9 v1.2 ✅ Validated compatible 2026-09-03 compatibility-v1.4.1-misp-core-v2.5.45.md
v1.4.1 release tag v2.5.44 v3.0.9 v1.2 ✅ Validated compatible 2026-07-31 compatibility-v1.4.1-misp-core-v2.5.44.md
v1.4.0 release tag v2.5.44 v3.0.9 v1.2 ✅ Validated compatible 2026-07-30 compatibility-v1.4.0-misp-core-v2.5.44.md
v1.3.1 release tag v2.5.44 v3.0.9 v1.2 ✅ Validated compatible 2026-07-23 compatibility-v1.3.1-misp-core-v2.5.44.md
v1.3.0 release tag v2.5.44 v3.0.9 v1.2 ✅ Validated compatible 2026-07-23 compatibility-v1.3.0-misp-core-v2.5.44.md
v1.2.0 release tag v2.5.44 v3.0.9 v1.2 ✅ Validated compatible 2026-07-22 compatibility-v1.2.0-misp-core-v2.5.44.md
v1.1.0 release tag v2.5.44 v3.0.9 v1.2 ✅ Validated compatible 2026-07-21 compatibility-v1.1.0-misp-core-v2.5.44.md
v1.0.0 release tag v2.5.44 v3.0.9 v1.2 ✅ Validated compatible 2026-07-15 compatibility-v1.0.0-misp-core-v2.5.44.md
v1.0.0 release tag v2.5.43 v3.0.8 v1.2 ✅ Validated compatible 2026-07-15 compatibility-v1.0.0-misp-core-v2.5.43.md
v1.0.0-rc.3 release candidate tag v2.5.43 v3.0.8 v1.2 ✅ Validated compatible 2026-07-15 compatibility-v1.0.0-rc.3-misp-core-v2.5.43.md
v1.0.0-rc.2 release candidate tag v2.5.43 v3.0.8 v1.2 ✅ Validated compatible 2026-07-13 compatibility-v1.0.0-rc.2-misp-core-v2.5.43.md
v1.0.0-rc.1 release candidate tag v2.5.43 v3.0.8 v1.2 ✅ Validated compatible 2026-07-12 compatibility-v1.0.0-rc.1-misp-core-v2.5.43.md
v0.3.3 release tag v2.5.43 v3.0.8 v1.2 ✅ Validated compatible 2026-07-12 compatibility-v0.3.3-misp-core-v2.5.43.md
v0.3.2 release tag v2.5.43 v3.0.8 v1.2 ❌ Validation failed 2026-07-12 compatibility-v0.3.3-misp-core-v2.5.43.md
v0.3.1 release v2.5.42 v3.0.8 v1.2 ⚪ Superseded historical validation 2026-07-08 real-world-v0.3.1.md

Important v1.4.1 is the latest published and latest validated-compatible release. The immutable v1.4.1 tag and published operator-bundle artifact passed the complete exact-tag/package-artifact lifecycle matrix plus an explicit remote reverse-proxy bind gate with core v2.5.45, modules v3.0.9, and guard v1.2. Official MISP Docker now defaults to core v2.5.48, modules v3.0.10, and guard v1.2 with a separated misp-nginx service. That newer architecture remains pending implementation and validation under issue #160. The earlier validated tuples remain retained evidence. PR-branch evidence remains capability evidence only and is not a substitute for exact-tag validation.

The v1.0.0 release tag remains historical validated evidence. Future manager releases or upstream component sets require separate validation before compatibility is claimed.

The v0.3.2 release tag is not marked validated compatible with MISP core v2.5.43. Validation exposed the known first-login readiness race that was fixed later on main and released in v0.3.3.

Status definitions

Status Meaning
✅ Validated compatible The listed manager release/ref and official MISP component set passed the documented scenarios.
🟡 Pending validation A new manager release or upstream MISP component set exists, but the combination has not completed validation.
❌ Validation failed The combination was tested and did not pass the documented scenarios; see linked notes or issues.
⚪ Superseded Historical validated evidence that remains useful but is not the newest recommended combination.

When compatibility must be revalidated

Compatibility validation is required whenever either side changes:

  1. This project publishes a new manager release.
  2. Official MISP Docker changes inputs that affect this installer, including:
  3. CORE_TAG, MODULES_TAG, or GUARD_TAG
  4. template.env
  5. docker-compose.yml
  6. image expressions
  7. service names
  8. required/default environment variables
  9. startup, migration, health, or readiness behavior

The scheduled upstream drift workflow detects many of these upstream changes and opens an upstream-review PR. That PR is a review prompt, not compatibility proof by itself.

Full compatibility scenario coverage

A full compatibility entry should cover at least:

Scenario Purpose
Direct-QA fresh install Proves a clean install path works with the component set.
Reverse-proxy fresh install Proves the reverse-proxy deployment shape works with the component set.
Install/update path Proves explicit component tags and update logic work together.
Backup/reset/no-lock-in lifecycle smoke Proves day-2 lifecycle helpers and upstream Docker Compose usability.
Failure-mode guardrail smoke Proves key safety checks fail closed before writing deployment state.

Browser automation may be recorded separately. If a compatibility run uses CLI login checks but not browser automation, the detailed report says so explicitly.

Public-safety policy

Public compatibility reports intentionally omit:

  • private hostnames and domains
  • private IP addresses
  • VM IDs
  • raw logs
  • credentials or generated secrets
  • internal topology or access paths
  • private repository URLs or local filesystem paths

The public report should show what was validated and what passed, while private raw evidence stays out of the GitHub repository.