ThreatConnect or OpenCTI for an open-source-first shop?

Hello everyone,

I've been evaluating our team's threat intelligence platform needs, and I've hit a familiar crossroads. As a shop deeply committed to open-source and cloud-native principles (we run everything on Kubernetes, use GitOps for deployment, and are big on observability), the choice between a product like ThreatConnect and an open-source project like OpenCTI is more than just a feature checklist exercise. It's about philosophy, operational overhead, and long-term sustainability.

From my research and hands-on testing, here's the core trade-off I see:

**ThreatConnect (TC)** offers a mature, all-in-one commercial product. Its strengths seem to be:
* **Integrated Workflow:** It bundles TAXII/STIX feeds, a collaborative SOAR-lite environment, and analytics into a single polished UI. You're buying a complete solution.
* **Reduced Operational Burden:** As a SaaS or self-hosted *application*, you're not responsible for deep database tuning or patching a complex stack of microservices. This is a significant DevOps time-saver.
* **Support & Roadmap:** You have a vendor to call, with a clear commercial roadmap and professional support SLAs.

**OpenCTI** represents the open-source stack approach:
* **Architectural Control & Integration:** It's built as a modern, modular platform (GraphQL API, Python/React). You can deeply integrate it into your existing ecosystem—think exposing indicators to your service mesh sidecars or feeding logs directly into your OpenTelemetry pipeline.
* **True Platform Flexibility:** Since you own the code and data model, you can extend it without vendor constraints. Need a custom connector to an internal tool? You build it.
* **Community & Transparency:** The development is in the open. You can inspect the code, contribute fixes, and adapt to your needs without licensing fees.

The operational overhead for OpenCTI, however, is not trivial. A production-grade deployment isn't just a `docker-compose up`. You're looking at managing:
* A multi-service Kubernetes deployment (Elasticsearch, Redis, RabbitMQ, the OpenCTI workers/platform)
* Data persistence and scaling for Elasticsearch
* The upgrade path for the entire stack

```yaml
# A snippet from a potential OpenCTI K8s deployment manifest shows the moving parts.
apiVersion: apps/v1
kind: Deployment
metadata:
name: opencti-platform
spec:
replicas: 2
template:
spec:
containers:
- name: opencti
image: opencti/platform:5.12.0
env:
- name: REDIS_HOST
value: "opencti-redis"
- name: ELASTICSEARCH_URL
value: "http://opencti-elasticsearch:9200"
- name: RABBITMQ_HOST
value: "opencti-rabbitmq"
# ... and so on for workers, connectors, etc.
```

For teams like mine, this complexity is a double-edged sword. We *can* manage it, but it diverts precious SRE and security engineering time from core tasks.

So, my question for the community is this: **For those running in an open-source-first, cloud-native environment, which path did you choose, and why?** I'm particularly interested in:

* **Long-term maintenance experience:** Has OpenCTI's operational burden been worth the flexibility?
* **Integration stories:** How deeply have you been able to weave either platform into your CI/CD, GitOps, or runtime security tooling?
* **Scale considerations:** How do both platforms handle at, say, the 10-million+ indicator level within a Kubernetes environment?

I'm leaning towards the idea that if you have the in-house container/platform expertise, OpenCTI could be a powerful, integrated component of your security data fabric. But if your team wants to focus on *using* intelligence rather than *maintaining* the intelligence platform, ThreatConnect's integrated model seems compelling.

Any war stories or architectural insights would be greatly appreciated.

—Chris