Skip to content

feat: migrate to a shared XTM Composer instance for OpenCTI and OpenAEV #86

Description

@ncarenton

Context

In SaaS, we currently deploy one XTM Composer per platform (OpenCTI and OpenAEV). For customers who have both products, this means two separate composer instances. We want to migrate to a single shared XTM Composer serving both platforms.

The codebase already supports this in theory — config/default.yaml has independent opencti and openaev sections, and src/main.rs spawns separate orchestration loops per platform. However, this has never been tested end-to-end.

Known Blockers

  1. Cleanup bug — orchestration loops delete each other's containers (see child issue)
  2. RSA key alignment — existing customers have different keys per instance; migration requires solving this (see child issue)
  3. Kubernetes namespace concern — may not work if platforms are in different namespaces (to be tested)

Metadata

Metadata

Assignees

No one assigned

    Labels

    featureType: new feature or capability (feat:).

    Fields

    No fields configured for Feature.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions