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
- Cleanup bug — orchestration loops delete each other's containers (see child issue)
- RSA key alignment — existing customers have different keys per instance; migration requires solving this (see child issue)
- Kubernetes namespace concern — may not work if platforms are in different namespaces (to be tested)
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.yamlhas independentopenctiandopenaevsections, andsrc/main.rsspawns separate orchestration loops per platform. However, this has never been tested end-to-end.Known Blockers