OpenCTI links threat facts back to people and sources
OpenCTI is built for intelligence analysis rather than a flat indicator feed. It stores technical observables alongside threat actors, campaigns, victimology, reports, confidence, and first or last seen dates. Relationships use a schema based on STIX 2, so an analyst can move from an IP address to the malware, intrusion set, report, and source that give it meaning. The web interface and GraphQL API sit on the same model.
Imports, exports, feeds, and connectors move data between OpenCTI and other security tools. The README names MISP, TheHive, and MITRE ATT&CK, while a separate connector catalog expands that surface. This is useful when several teams need one evidence trail. It is excessive when the task is only to publish 20 indicators or subscribe to a few feeds, because the knowledge graph and connector lifecycle become additional systems to govern.
The official deployment needs at least four stateful dependencies
The production design is distributed. OpenCTI depends on Elasticsearch or OpenSearch for search, Redis for streams and coordination, RabbitMQ for work messages, and an S3-compatible bucket for files. Workers consume RabbitMQ jobs. The official Docker repository supplies Compose files, while the application repository we measured has no Dockerfile. Manual, Helm, and Terraform routes are documented too.
Capacity planning starts above hobby-server territory. The documentation says the Node runtime has an 8 GB default memory limit. Its default Redis stream can hold 2 million entries and use around 8 GB, before search, object storage, RabbitMQ, workers, connectors, and the web application are counted. A proof of concept can run smaller, but a production budget must come from retention, ingestion, connector count, and query load.
What happened when we ran it
Our sandbox installed 140 Yarn packages in 10 seconds at commit fd1cfda and used 73 MB after installation. The source tree itself was far larger: 6,593 files, roughly 895,190 lines of source, and 223.1 MB checked out. We found 20 CI workflow files, no root Dockerfile, and no tests directory. The install step succeeded in an unprivileged Node 22 Debian container with 3 CPUs and 8 GB of RAM.
The build failed after 15 seconds with exit 130. The final output says Nx could not complete the build target for two projects because opencti-graphql:build failed. It also says opencti-front:build was not run because its dependency failed or --nx-bail=true stopped the graph. The supplied log tail contains no lower-level compiler or runtime exception, so it does not support a claim about the cause.
The test tail names four failed targets without their exceptions
Our test command failed after 13 seconds with exit 1. Nx named opencti-graphql:test, opencti-front:test, opencti-worker:dev, and opencti-front:e2e as failed tasks. The summary reports a 2.5-second Nx run, a 1.3-second critical path, and 0 of 1 cached tasks. It does not provide individual test cases or a passed-test count.
That distinction matters. We cannot say the application logic is broken, that services were missing, or that Node 22 is incompatible from the tail alone. We can say the documented repository commands did not produce a green build or test result in our fresh 8 GB container. Anyone choosing a source deployment should reproduce both commands in the intended environment before planning custom connectors or patches.
Community and Enterprise editions use different terms
The README describes 2 editions. Community Edition uses Apache 2.0, while Enterprise Edition has its own license and adds paid capabilities. GitHub therefore reports no single SPDX license for the whole repository. Evaluate the Community feature set against requirements before treating OpenCTI as a cost-free replacement for a commercial CTI platform. Licensing and operations are separate decisions.
OpenCTI also sends anonymous usage statistics to Filigran when the telemetry endpoint is reachable. The documentation says pushes occur every 6 hours and exclude threat-intelligence content, personally identifiable information, and IP addresses. It lists platform, user-count, connector, feature-use, authentication, and AI-feature metrics. Regulated deployments should review that list, outbound network policy, and support-package logs before production.
September activity is high despite a queue of 2,188 items
GitHub showed 10,064 stars and 2,188 open issues and pull requests on September 29, 2026. That combined number is not a bug count. The repository was pushed the same day, and active work included dependency updates, connector fixes, observability, workflows, and configuration export. Release 7.260928.1 shipped one day earlier with a connector auto-upgrade fix. Maintenance is plainly active.
OpenCTI is credible for an organization building a real CTI practice, especially when STIX relationships and source attribution are central. Our failed 15-second build and 13-second test run prevent a clean recommendation for source contributors at fd1cfda. Start with the official deployment path, size the four stateful dependencies, confirm which edition contains the needed controls, and require a green environment-specific build before modifying the platform.