What OpenCTI high availability actually requires
High availability for OpenCTI is a set of decisions spread across the whole stack, and running several platform nodes is only one of them. Analysts who rely on OpenCTI during an incident need the interface and GraphQL API to answer, while threat intelligence feeds and connectors keep writing data in the background. A team can run multiple platform nodes and still lose search, ingestion or queued writes when one stateful dependency fails. The question to answer first is which component can fail, what users will see when it does, and who is responsible for restoring it.
The deployment is made of the platform (UI and GraphQL API), Python workers that consume RabbitMQ messages for asynchronous writes, and connectors for import, enrichment, file extraction, export and stream consumption. The supporting services are Elasticsearch 8.0 or OpenSearch 2.9 or later, Redis 7.1 or later, RabbitMQ 3.11 or later, and S3-compatible storage such as MinIO. Each one needs its own answer on node count, placement across failure domains, replication and failover. Your team should record those answers before choosing hardware or cloud services, because the search tier, the queue and the cache each carry different recovery behavior. Confirm the exact supported multi-node topology against the documentation for the release line you plan to run, since the supported arrangements can change between releases.
The platform nodes are the easy part to scale, because they hold little state of their own. The difficulty sits in the stateful dependencies. Search, Redis, RabbitMQ and object storage hold the data, the queues and the coordination state, so a failure there can affect every user even when all platform nodes are healthy. Asynchronous writes add a second concern. A change accepted by the platform may still be waiting in a RabbitMQ queue when a node or worker fails, so the gap between accepted and persisted data is part of your recovery design. Ask how queues are persisted, how unacknowledged messages are redelivered, and how a worker restart is handled without duplicating or losing intelligence.
Connector load makes these failure modes more likely to matter. A large feed import or an enrichment run can generate a burst of writes that fills queues and slows search indexing, and that pressure is hardest to absorb during a failover. The documented sizing recommends at least one platform node for every 3 workers, which is a starting point for planning rather than a guarantee for your connector mix. Measure worker throughput with the connectors you actually run, and decide in advance which feeds can be paused during an incident so that analyst queries keep priority.
A topology on paper is not evidence that recovery works, so the team should plan recovery tests before go-live and repeat them after each upgrade. Useful tests include stopping one search node, failing over the Redis primary, restarting a RabbitMQ node under load, and restoring object storage from a backup into a separate environment. Write down the expected behavior for each test, including what analysts can still do and how long a queue can take to drain, then compare the results with that record. If you are unsure how a dependency behaves in your chosen configuration, confirm it with the vendor documentation for your release line before you rely on it during an incident.
Which OpenCTI components need redundancy and which do not
Not every OpenCTI component needs the same redundancy. The platform and workers scale out, while the search index, message broker and object storage hold data that must survive a node loss. Use each card to decide where to add nodes and where backups matter more.
Platform nodes (UI and GraphQL API)
The platform serves the web application and GraphQL API that analysts and connectors call. Running more than one node keeps analyst access available if one node fails, provided a load balancer or ingress stops routing traffic to the failed node. The documented guidance recommends at least one platform node for every 3 workers, so check this ratio against your planned worker count before fixing the node count. Confirm with Filigran's deployment documentation how sessions and uploads behave across nodes.
Python workers
Workers consume RabbitMQ messages and perform the asynchronous writes that the platform queues, so they set ingestion throughput. If one worker stops, its pending messages wait for another consumer, and ingestion slows until capacity returns. Analyst searches are not affected by a single worker failure. Check the worker count against the one platform node per 3 workers ratio, and leave the detailed worker sizing to the sizing topic.
Connectors for import, enrichment and export
Connectors import feeds, enrich observables, extract files, export data and consume streams. A failed connector typically affects only the data source it handles, so the impact is narrower than a platform or storage failure. Decide which connectors feed time-sensitive intelligence and need a standby. For each one, confirm in its documentation whether it can run more than one instance and how it resumes after a restart.
Elasticsearch or OpenSearch index
The search index holds the data analysts query, which makes it the most stateful component in the stack. The supported versions are Elasticsearch 8.0 or OpenSearch 2.9 or later. Redundancy here means a clustered index with replicas, so losing one node does not remove data or stop searches. Confirm replica and shard settings against your data volume, and test a node-loss scenario before go-live.
RabbitMQ message broker
RabbitMQ holds the messages that workers consume for asynchronous writes, so pending work lives in the broker until a worker processes it. The supported version is RabbitMQ 3.11 or later. Check whether your broker topology uses clustering and quorum queues, and confirm the message persistence settings. Without them, a broker restart can drop writes that were accepted but not yet processed.
Redis and S3-compatible storage
Redis (version 7.1 or later) and S3-compatible storage such as MinIO support the platform. Ask Filigran whether losing Redis contents only clears transient state or forces a rebuild, since that answer sets how much standby capacity Redis needs. Object storage holds uploaded files, so losing a bucket removes those files unless it is replicated or backed up. Plan bucket replication and backups as a separate work item.
Which OpenCTI high availability topology fits your team
This table compares the main OpenCTI high availability topologies, how the dependencies are run, and which release line to follow. Read each row as a decision: the middle column says when the option suits a team, and the right column lists the patching, on-call, backup and testing work you take on. The main takeaway is that each step up in redundancy adds components you must operate, so start with the smallest topology that meets your availability requirement.
| Option | When it fits | Operational cost to you |
|---|---|---|
| Single platform node with workers and managed dependencies | Small teams that can tolerate a restart window during upgrades or node failure | Scheduled patching of one platform node and its workers, plus restore from backup after a failure |
| Multiple platform nodes behind a load balancer with shared dependencies | Analysts need UI and API access during maintenance; platform nodes hold no state of their own | Rolling upgrades across nodes, load balancer health checks, and failover tests; backups must still cover search and object storage |
| Fully clustered search, queue and cache layers | Large data volumes or many connectors where one Elasticsearch or OpenSearch, Redis or RabbitMQ instance would be a single point of failure | Cluster-specific upgrades, shard and quorum monitoring, larger restore tests, and on-call skills for each service |
| Self-managed dependency clusters | Your team already runs search, queue and cache clusters and wants control over versions and placement | Your team patches, scales and snapshots each service, and the on-call rota must cover every one of them |
| Operator-managed or cloud-managed dependencies | Your team wants the provider to handle node replacement, minor patching and snapshots | Less patching effort, but you must confirm supported versions against the OpenCTI minimums and check snapshot export options |
| LTS release line | Regulated teams that need predictable change windows; LTS builds require a specific LTS license key | Upgrade roughly every six months; each line is supported for one year and receives only critical bug and security fixes after stabilization |
| Continuous releases | Teams that want new features and fixes quickly and can test often, using non-LTS builds that ship from daily to weekly | Frequent upgrade testing against connectors and data, short change control cycles, and a tested rollback plan for each release |
How RabbitMQ, workers and search behave when one part fails
The most useful thing to understand about an OpenCTI high availability design is that the platform does not write most data directly to the search cluster. The platform publishes work, RabbitMQ holds the messages, Python workers consume them, and the workers write the results to Elasticsearch or OpenSearch. Each hop is a place where a failure looks different to an analyst, so the failure behavior of each part should be confirmed before the design is accepted.
When a platform node restarts, the design goal is that other platform nodes continue to serve the UI and GraphQL API behind the load balancer. Analysts with sessions on the restarted node may need to sign in again or retry a request. Work already published to RabbitMQ is not lost because the queue sits outside the platform node. Confirm with the vendor documentation for your version how in-flight API requests and sessions are handled during a rolling restart, and whether your load balancer health checks drain the node cleanly.
When a worker stops, the main risk is delay rather than data loss. Messages that a worker had accepted but not acknowledged should return to the queue for another worker to pick up, and ingestion and enrichment should slow in proportion to the lost capacity. Analysts may see entities appear late or enrichment remain pending. Recommendation: check how many workers are needed to keep normal ingestion running with one worker down, and set alerts on queue depth and worker count so the backlog is noticed early.
When RabbitMQ or Redis is unavailable, plan for the platform to show errors or stale data while the dependency is down. Whether writes are rejected, queued in memory, or retried depends on the OpenCTI version and the client settings in your deployment, so this must be confirmed rather than assumed. Ask the vendor how message durability works for your version, including whether queues are declared durable and whether published messages are persisted to disk. Ask which Redis features the platform depends on and whether a Redis failover causes a session or cache reset.
When the search cluster loses a node, the outcome depends on shard replication, the number of data nodes left, and the index settings applied during deployment. A healthy cluster with replicas should keep serving reads and writes, but a cluster that drops below quorum or lacks replicas can turn red and stop accepting writes. Analysts may see slow searches or missing results until shards recover. Before go-live, run each of these failures in a non-production copy, record what analysts see at each step, and agree the recovery steps with the team that operates the search cluster.
How to build OpenCTI high availability in order
This sequence takes an OpenCTI deployment from a single instance to a highly available layout with clustered search, shared queues and storage, several platform nodes and workers, and a tested failover. Each step ends with a check that shows it is complete before the next one starts.
Fix the release line and license
Decide whether the deployment follows the continuous release line or the licensed LTS line, and confirm which edition each required feature needs. Community Edition is licensed under Apache License 2.0, while Enterprise Edition is required for SSO, and LTS releases need a specific LTS license key. Record the exact date-based version you will pin and read its release notes before writing any image tags. Done when the pinned version, edition, license key owner and upgrade approver are written in the build sheet.
Provision and secure the search cluster
The platform team builds an Elasticsearch 8.0 or later, or OpenSearch 2.9 or later, cluster with replica shards so that losing one data node does not take intelligence offline. Size each node against the documented minimum of 2 cores, 8 GB RAM and 16 GB SSD, and plan extra capacity for growth. Enable authentication, restrict network access to platform and worker subnets, and store credentials in your secrets manager. Done when cluster health is green, replicas are assigned, and a test document can be written and read from each platform subnet.
Deploy Redis and RabbitMQ with persistence
Deploy Redis 7.1 or later and RabbitMQ 3.11 or later as shared services used by every platform node and worker. Enable persistence on both so that queued messages and cached state survive a restart, and require authentication with a separate least-privilege account for each service. Place both on a private network segment reachable only from platform and worker nodes. Done when a controlled restart of each service leaves queued messages in place and the platform reconnects using the credentials you set.
Place S3-compatible storage for files
Provision S3-compatible object storage, such as MinIO, that all platform nodes and workers reach for uploaded files and exports. Create a dedicated bucket with an access key limited to that bucket, enable versioning or your provider's equivalent protection, and confirm the endpoint uses TLS. Ask your storage vendor which replication or erasure coding options apply, since they determine how the bucket survives a disk or site loss. Done when a test file uploaded through the shared endpoint from one node can be retrieved from a second node.
Deploy two or more platform nodes
Start at least two platform nodes from the same pinned image, each sized to the documented minimum of 2 cores and 8 GB RAM, and point all of them at the same search, Redis, RabbitMQ and storage endpoints. Place them behind a load balancer that terminates TLS with certificates from your certificate authority. Check the documented session and authentication behavior for your version before choosing sticky sessions or a shared session store. Done when both nodes answer through the load balancer, the UI and GraphQL API respond from each, and a signed-in session survives the removal of one node.
Add workers at the platform ratio
Deploy Python workers that consume RabbitMQ messages for asynchronous writes. The documented guidance is at least one platform node for every 3 workers, so two platform nodes support up to six workers at that ratio. Add workers in steps and confirm each one registers with the platform and consumes from the queue. Done when the worker count matches the ratio for your platform node count and queue depth returns to a steady level under a test load.
Point connectors at the shared queue
Configure each connector with the platform URL, the RabbitMQ endpoint and its own token so that all of its messages move through the shared queues. Cover the connector types you plan to run for import, enrichment, file extraction, export and stream consumption, and check the setup guide for the version you pinned. Confirm each connector reconnects after a broker restart. Done when a test import creates objects visible through the load balancer and the queue shows those messages consumed by workers.
Run a controlled failover test
Write a test plan that stops one platform node, one worker and one dependency at a time, with a named owner and a rollback step for each. Run each test in an agreed window while a connector import is in progress, and record whether the UI stays reachable and whether queued messages are processed after recovery. Repeat the tests after any change to the release line or topology. Done when every failure has a recorded result, the runbook reflects the observed behavior, and the team has signed off on the backup and recovery plan.
How the HA layout changes for single node, Kubernetes and air-gapped sites
A single-node pilot runs the platform, workers, search, Redis, RabbitMQ and object storage on one host or a small container set. It is useful for proving connectors, data model and access design before the production cluster is sized. The layout is not highly available, so it should be labelled as a pilot and carry a written path to scale.
- Build: Keep the same dependency versions and configuration keys planned for production, so scaling out changes addresses and replicas instead of forcing a rebuild.
- Build: Start from the documented minimums for the platform and search components, then add workers as connector volume is measured.
- Harder: One host failure stops ingestion, search and the user interface together, so backup and restore is the only recovery path.
- Harder: Search and queue workloads compete for the same memory and disk, and contention often stays hidden until data volume grows.
- Confirm: Whether the pilot licensing and any LTS key permit promotion to production, and which steps the vendor or your platform team requires for scale-out.
Confirm the scale-out steps in writing before pilot data becomes something analysts depend on.
A multi-node virtual machine layout separates the platform, workers and stateful services across hosts so that one host failure does not stop the service. Platform nodes are stateless and sit behind a load balancer, while workers consume RabbitMQ messages for asynchronous writes. The documented guidance is at least one platform node for every three workers, which sets the baseline for node counts.
- Build: Place platform nodes and workers on separate hosts, spread search, Redis and RabbitMQ members across hosts, and use hypervisor anti-affinity rules where available.
- Build: Provision object storage with its own redundancy, since S3-compatible storage holds file content outside the search index.
- Harder: Quorum for the search cluster and the queue cluster must survive planned patching, so the patch order matters.
- Harder: Consistent backups need coordinated snapshots across search, object storage and database state, which is harder than backing up a single host.
- Confirm: Which Redis and RabbitMQ clustering modes the vendor supports for your OpenCTI version, whether session handling works across platform nodes behind your load balancer, and where TLS terminates.
Run a failover test on a non-production copy and record the recovery time you observe before signing off the layout.
In Kubernetes, the platform and workers run as pods managed by a deployment, while search, Redis, RabbitMQ and any object storage run as stateful workloads with persistent volumes. Availability depends on how the scheduler places pods, how volumes are provisioned and how node maintenance evicts stateful pods. The application can be stateless, but the data layer still needs careful design.
- Build: Use StatefulSets for search, Redis and RabbitMQ members, with a storage class that supports the replication and snapshot behavior you need.
- Build: Set pod anti-affinity, readiness probes and pod disruption budgets so that drains never remove quorum members at the same time.
- Harder: Storage class performance and reclaim policies vary by cluster, and a misconfigured reclaim policy can delete data during a redeploy.
- Harder: Node drains and cluster upgrades must be sequenced with the search and queue quorum, which adds steps to every maintenance window.
- Confirm: Whether the vendor publishes a supported Helm chart or operator and where its support boundary sits, which Kubernetes versions are supported, and whether your storage class supports volume snapshots for backup.
Before committing, ask for the exact manifests or chart version you will run, and test a node drain against a restored copy of the data.
An air-gapped deployment has no direct route to public registries, package indexes or feeds, so every image, dependency and update must be planned in advance. The build is the same set of components, but the supply chain moves inside your boundary. Container images for the platform, workers and connectors must be mirrored into an internal registry before installation.
- Build: Mirror the platform, worker and connector images, plus the Elasticsearch or OpenSearch, Redis, RabbitMQ and MinIO images, into an internal registry, and record the version of each.
- Build: Plan LTS license key handling: LTS releases are distributed as container images but require a specific LTS license key to use.
- Harder: Each update arrives as a transfer bundle, so upgrades run on a planned cycle instead of as they are released.
- Harder: Connectors that normally pull external feeds need an internal proxy, a local copy of the data or an approved offline source.
- Confirm: Whether the license terms allow offline use and how keys are renewed, whether the vendor provides offline bundles, and which connectors require outbound access.
Document the image digests and key expiry dates in your change records, because you will need them during the next upgrade and any audit.
What drives the effort and cost of OpenCTI high availability
This table lists the factors that change how much design, build and ongoing work an OpenCTI high availability setup needs, and how to keep each one under control. Read it before requesting a quote, because each driver should appear as a line item or stated assumption in the written scope. Costs split into one-time design and build work and recurring patching, testing and on-call work.
| Driver | How it raises effort | How to keep it down |
|---|---|---|
| Analyst and user count | More concurrent users increase platform node count, load testing scope, and the number of access and role configurations to validate. | Confirm peak concurrent users in writing, size platform nodes against that figure, and phase user onboarding by team. |
| Data volume in the search index | Larger Elasticsearch or OpenSearch indices require more shard planning, longer reindex and restore times, and bigger capacity tests. | Set retention rules early, separate high-volume feeds, and agree a data volume estimate that the quote is based on. |
| Number of connectors and their schedules | Each connector adds worker capacity needs, queue load on RabbitMQ, and monitoring. Overlapping schedules create write peaks. | Start with the connectors that deliver value, stagger import schedules, and size workers from a measured connector list. |
| Number of environments (dev, test, production) | Each environment needs its own dependencies, configuration, backup jobs and upgrade testing, multiplying build and recurring work. | Use smaller non-production clusters with scripted deployments, and document which differences from production are accepted. |
| Backup retention and recovery evidence | Longer retention periods, encrypted off-site copies and documented restore tests add storage, scheduling and evidence-gathering work. | Agree retention periods with your compliance owner before design, automate backups, and schedule restore tests with recorded results. |
| Network isolation of dependencies | Separating Elasticsearch or OpenSearch, Redis, RabbitMQ and object storage into restricted zones adds firewall rules, service accounts and TLS configuration. | Define the traffic flows once in a diagram, reuse one network pattern across environments, and confirm the design with your security team early. |
| Team skills with Elasticsearch or OpenSearch, Redis and RabbitMQ | Teams without experience in these services need more design review, knowledge transfer and time to diagnose failures during on-call. | Ask the partner to include operator handover and runbooks in scope, and confirm which skills your team already has before the build starts. |
Securing the HA layer: secrets, network paths and access between nodes
Running several OpenCTI platform nodes and workers multiplies the places where credentials, tokens and network paths must be controlled. The cards below cover only the controls that change because of redundancy, while the security hardening topic covers the full baseline.
Secrets shared across platform nodes
Every platform node and worker needs the same dependency credentials and API tokens for Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage. Confirm that these values are injected from a secrets store at start-up rather than copied into per-node configuration files, and that rotating one credential is a single controlled change that every node picks up. Check that no secret appears in container images or logs.
Network isolation of shared dependencies
Redis, RabbitMQ and the search cluster should accept connections only from OpenCTI platform nodes and workers, not from user subnets or other application tiers. With several nodes and workers, the allowed source list grows with every scale-out step, so define it by role or security group rather than by individual addresses. Test the policy by attempting a connection from an unlisted host.
TLS between nodes and the load balancer
Traffic from users to the load balancer, from the load balancer to platform nodes, and from nodes to the shared dependencies can each be encrypted separately. Decide which hops terminate TLS and which use internal certificates, and confirm that certificate renewal does not require restarting the whole cluster at once. Verify the chain on every node, since a single misconfigured node can fail intermittently behind the balancer.
Authentication of connectors to the queue
Connectors and workers publish and consume messages through RabbitMQ, so each connector should have its own RabbitMQ identity with permissions limited to the queues it uses. Shared accounts make it hard to trace which connector produced a message or to revoke one connector without affecting the rest. Confirm the account model with your connector list before the first scale-out.
Least-privilege service accounts for storage
The platform and workers need to read and write only the buckets and indices they use. Create separate service accounts for the object storage and the search cluster, and avoid administrator credentials in platform configuration. Review these permissions whenever a new worker type or connector is added, because redundancy tends to extend access by default.
How to test that OpenCTI high availability works and fails safely
A high availability claim for OpenCTI is only credible once the team has deliberately broken each part and recorded what analysts saw. Run this test plan in a non-production copy built the same way as production, with the same platform node count, worker pools, RabbitMQ and search cluster layout, and the same load balancer in front of the platform nodes. Five tests cover the failure modes that matter most: platform node loss, worker restart, RabbitMQ restart, search node loss, and restore from backup. Agree the pass and fail criteria for each test before the first one starts, so the team does not judge results after seeing them. Ask your implementation partner or the vendor to confirm which RabbitMQ settings control queue durability and message persistence in your version, because those settings decide what the broker test should show.
Test one stops a single platform node while a group of analysts keeps working. The expected behavior is that the UI and GraphQL API keep answering through the load balancer, existing sessions either continue or re-authenticate cleanly, and searches and edits return no server error beyond a brief reconnect. Also send requests directly to each remaining node, since a healthy load balancer path can hide a broken node. Test two restarts one Python worker while a known connector import is active. The expected behavior is that consumption resumes on the remaining or restarted worker, the RabbitMQ queue depth drains back toward its prior level, and the objects created by the import appear in the UI. A test fails if queued messages stop draining, if work is duplicated or lost in a way the team cannot explain, or if a stopped node still receives traffic.
Test three restarts RabbitMQ while messages are waiting in its queues. The configuration intent is that durable queues and persistent messages survive the restart, so create a marker set of objects, confirm the messages are queued, restart the broker, and confirm the workers process them after recovery. If your configuration does not persist messages, the expected result differs and must be written down before the test runs. Test four stops one node in the Elasticsearch or OpenSearch cluster and checks cluster health. Green means all primary and replica shards are allocated, yellow means primaries are available but some replicas are not, and red means some data is unavailable. Analysts should keep working through yellow. A test fails if health goes red, if searches return partial results without any warning, or if the cluster does not return to its prior state after the node rejoins.
Test five restores a recent backup into a separate environment, never over the live system. Compare object counts by type against the counts recorded when the backup was taken, then open a sample of relationships chosen across several entity types, including relationships to files, marking definitions and organizations. A test fails if counts differ without a documented reason, if sampled relationships are missing or point to the wrong objects, or if the restored platform cannot start cleanly against its dependencies. Record every test as handover evidence: the date, the environment, the software versions, the person who ran it, the exact steps, the observed results against the agreed criteria, and any deviation with the fix applied. Store the record where operations and the next responder can find it, and repeat the full plan after any upgrade or topology change.
What to monitor, back up and document after go-live
A highly available OpenCTI cluster only stays available if someone watches its dependencies, can restore them, and knows how to change them safely. The cards below cover monitoring, backup scope, restore testing, upgrades and runbooks, and each one carries an ongoing operating cost that should be planned before go-live.
Monitor each node and dependency
Track platform node health, worker health and RabbitMQ queue depth separately, because a growing queue usually means workers are falling behind before any user sees an error. Watch search cluster health, Redis memory use and availability, and storage access from the S3-compatible store. Set alerts on each signal so a single failed dependency does not appear first as slow searches or missing data.
Back up search indices
Elasticsearch or OpenSearch holds the indexed intelligence that analysts query, so its indices belong in the backup scope with snapshots stored outside the cluster. Confirm with your search platform's documentation how snapshot repositories are registered and how restores interact with the OpenCTI index layout. Record which indices were captured in each snapshot so a restore can be checked against expected content.
Back up Redis and RabbitMQ state
Decide which Redis data must survive a restore, since cached and transient keys may be rebuilt while other state may not. For RabbitMQ, export queue, exchange, binding, user and policy definitions so the broker can be recreated on a new node. Note that messages still in flight are a separate question from definitions, and confirm with your team how pending writes are handled after a broker loss.
Back up S3 buckets and configuration
File attachments and exports live in the S3-compatible bucket, so back it up with versioning or replication and keep its access policies under the same review. Store the platform configuration, connector settings and secrets references in version control or a secrets manager, not on a single node. A restored bucket with a mismatched configuration can leave the platform running with broken file links.
Set the backup schedule and run restore drills
Set a backup frequency for each component based on how much intelligence your team can afford to re-ingest, and document the retention period and who approves deletion. A backup that has never been restored is an untested assumption, so schedule restore drills into a separate environment at a regular interval. Record how long each drill took and which steps failed, because those results shape the recovery time you can honestly promise.
Plan upgrades with a test environment
Choose between the continuous release line and the licensed LTS line before the first upgrade window, since the two differ in cadence, support period and license requirements. Test each upgrade against a copy of your data and your connectors, including the connectors that write the most objects. Check the release notes and the product life cycle documentation for the version you plan to run, and confirm the LTS license terms with Filigran before committing.
Write the failover and rebuild runbook
Write one runbook covering platform node failover, node replacement and dependency rebuild, with the exact order of steps and the person who can authorize each one. Include how to rejoin a rebuilt search node, how to drain and restart workers, and how to verify that queues are consumed after recovery. Keep the runbook in a location that survives the outage it describes, and review it after every drill or upgrade.
Questions teams ask before building OpenCTI high availability
How much effort and cost does OpenCTI high availability add to a project?
The cost depends mainly on how many platform nodes, workers, search nodes, Redis and RabbitMQ components, and object storage your design needs, and on how many environments must be built and tested. Each clustered dependency adds configuration, monitoring, backup and failover testing work, and identity integration adds more if you use SSO. Most of the spend is one-time build work, while infrastructure, licenses and support recur. When you request a quote, ask for the work broken down by component (platform, workers, Elasticsearch or OpenSearch, Redis, RabbitMQ, storage, backup and recovery testing), by environment, and by one-time versus recurring cost. Ask which licenses are included and which you must buy separately, such as the Enterprise Edition license needed for SSO. Ask what is excluded from the fixed scope.
How long does it take to build OpenCTI high availability?
The duration depends on the scope of the design, the number of environments, how much of the infrastructure already exists, and how much data and how many connectors you need to validate before cutover. A single production cluster with a staging copy takes less time than a multi-region design with separate test, pre-production and production environments. Timelines are set per engagement, so ask for the schedule to be written into the scope with milestones for the platform tier, the search and queue tier, the backup and recovery tests, and the cutover. Confirm which items depend on your teams, such as network approvals, account access and change windows, because those often set the critical path.
Can our own team build OpenCTI high availability without outside help?
Yes, a capable team can build it alone if it has the right skills and enough time to test the design. The work needs people who can operate Linux hosts and containers, run a clustered Elasticsearch or OpenSearch deployment, configure Redis and RabbitMQ with the documented minimum versions (Redis 7.1 or later, RabbitMQ 3.11 or later), manage S3-compatible object storage, and set up identity integration and backups. Someone also needs to own the OpenCTI configuration, connector behavior and release process. Ask yourself whether you have people who can run failover and restore tests, not only a successful install. Outside help is most useful when the team lacks one of these skills or has no time to validate the design before production.
What does an OpenCTI high availability engagement need from our side?
The work needs access, environments, sample data and named decision owners. You will need accounts and network access in your cloud, data center or air-gapped network, plus approval for the hosts, storage and ports the design uses. Staging or test environments should exist early so that failover and upgrade tests can run before production. Sample data helps validate indexing, connector volumes and access rules, and it should be handled under your data-handling rules. You also need decision owners for the architecture, identity model, backup retention and change windows, and someone who can accept the license terms. Ask for these requirements to be listed in the written scope so delays can be traced to a named item.
Is an OpenCTI high availability design compatible with an LTS license?
Yes, the design can be built on the LTS line, but the license matters. OpenCTI LTS releases are distributed as container images and need a specific LTS license key to use. LTS versions are numbered in the x.YYMMDD.z-lts.n pattern, and a new LTS line appears every 6 months. Each LTS line is supported for 1 year, which gives a 6-month overlap between consecutive versions. After a one-month stabilization period, an LTS release receives only critical bug and security fixes. Confirm with Filigran which LTS line your license covers, how long your key remains valid, and whether your edition includes the features you need. Plan the cluster so a move to the next LTS line fits inside the support overlap.
What happens during an OpenCTI release upgrade in a clustered setup?
An upgrade touches every tier, so it should be run as a planned change with a rollback path. Before you start, read the release notes, confirm the required versions of Elasticsearch or OpenSearch, Redis, RabbitMQ and object storage still match the platform release, and back up the search index, object storage and any persistent queue or cache state your configuration uses. Then upgrade a staging cluster that mirrors production, including the connector and worker versions. Test ingestion, enrichment, exports and logins before you touch production. In production, upgrade the nodes in a controlled order and check worker and connector health after each step. Do not promise zero downtime to stakeholders until your own tests show it works for your topology.
How do backup and recovery plans change once OpenCTI runs in a cluster?
Clustering makes the recovery plan more complex because the platform, workers, search data, queues and object storage must stay consistent with each other. Define what must be restored, in what order, and how you will confirm the restored system matches the data you expect. Object storage, search indexes and the database-backed platform state need consistent backup points, and you should check how Redis and RabbitMQ persistence is configured in your environment before you rely on it. Test a full restore into a separate environment on a schedule, and record the time it takes and what needed manual work. Ask the team building the design to document the restore runbook, the recovery point each component can meet, and who decides when to fail over.
How DeployOpen scopes, builds and hands over OpenCTI high availability
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, so OpenCTI high availability runs in your cloud account, data center or air-gapped network. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Map which platform nodes, workers, Elasticsearch or OpenSearch, Redis and RabbitMQ components need redundancy in your environment
- Record the documented minimum dependency versions and the target sizing agreed with your team
- Agree in writing how backup, recovery and failover tests are covered before any work starts
How we build
- Deploy multiple stateless platform nodes and workers behind a load balancer in your environment
- Configure clustered search, queue and cache layers, plus S3-compatible object storage for shared files
- Test failover of each dependency and confirm workers keep consuming RabbitMQ messages during a node loss
How we hand over
- Deliver architecture diagrams, configuration records and runbooks for each high availability component
- Document backup schedules, restore steps and recovery checks with your operations staff
- Walk your platform and security teams through failover testing results and open items
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, scoped in writing
- Review sizing and dependency versions as data volume and connector counts grow
- Confirm with your team which release line, such as the LTS line, the high availability design must follow
