What upgrades and support involve for OpenCTI
An OpenCTI upgrade is never just a web application change. A self-hosted deployment runs the platform, Python workers, connectors, Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage, and each of these components has its own version requirements. The documented minimums include Elasticsearch 8.0 or OpenSearch 2.9 or later, Redis 7.1 or later and RabbitMQ 3.11 or later. Before any change is scheduled, the operations owner should inventory every component version in the environment, including each connector image, and confirm which of them the target OpenCTI release supports.
Four events usually start an upgrade. The first is moving between the regular release line and an LTS line, which changes both the version number format and the licensing requirement. The second is an LTS line reaching end of support, which leaves the team with a fixed deadline. The third is a connector or dependency that needs a newer platform or library version to work. The fourth is a security fix. Teams should confirm in the release notes and life cycle documentation which of these applies to their current version before deciding how quickly to act.
Teams with a named operations owner, a staging environment that mirrors production and enough capacity to roll back are often able to handle routine patching in-house. A partner is usually more useful when the upgrade crosses several components at once, when connectors and live data must be tested before cutover, or when the organization wants retained support so that fixes and advice are available between planned upgrades. Ask any partner to show how they would test connector behavior and data migration in a copy of your environment, not only how they would install the release.
What the work includes
An OpenCTI upgrade touches the platform, its workers, every connector and the data stores beneath them. The service breaks that work into the components below, and each one ends in a document or check you keep.
Release channel decision
Choose between regular releases, which ship from daily to weekly, and the LTS line, which is released every 6 months, supported for 1 year and requires a specific LTS license key. We document the choice against your change window, patch tolerance and licensing. Deliverable: a written release channel decision record with the upgrade cadence it implies.
Upgrade assessment of the platform
We compare your running version with the target version and read the release notes for schema, configuration and authentication changes. We check that Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage meet the documented minimum versions for the target. Deliverable: a written upgrade assessment with a list of required pre-upgrade changes.
Workers, connectors and dependencies
Python workers and each connector are inventoried with their current and target versions. We build a compatibility matrix for your connectors, flag any that lag the platform release, and confirm worker capacity against the platform node ratio. Deliverable: a version compatibility matrix for your connectors and a dependency map.
Staged upgrade in non-production
We rebuild a non-production environment from a copy of your configuration and a representative data set, then run the upgrade through it end to end. Connector imports, enrichments and exports are tested against the new version before any production change. Deliverable: a staging test report that records results, defects and fixes.
Cutover and rollback plan
The cutover plan sets the order of platform, worker and connector changes, the freeze on new connector runs and the checkpoints where the team decides to continue or stop. The rollback plan states how to restore the previous version and its data state if a checkpoint fails. Deliverable: a written cutover plan and rollback runbook.
Post-upgrade verification
After cutover we check login paths, GraphQL API behavior, worker queues, connector runs and search results against the checklist agreed in staging. Any gap is logged with an owner and a fix or accepted risk. Deliverable: a signed-off verification checklist and a post-upgrade handover note.
Ongoing support tiers
Between upgrades, support covers monitoring of new releases, hotfixes for your LTS line, connector maintenance and dependency updates. Tiers are set by the response and upgrade commitments you need, and they are agreed in a retainer. Deliverable: a written support scope with service levels defined in the retainer.
What drives effort and frequency
This table compares the factors that change how often an OpenCTI installation needs upgrading and how much testing each upgrade requires, with a way to keep each one under control.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Number and type of connectors | Import connectors pull external feeds and enrichment connectors call outside services, so each type carries different upgrade and test exposure. | Limit the set to sources you actively use, and give each connector an owner and a regression check. |
| Number of environments | Each environment is a separate upgrade target, so one release becomes several rounds of testing and promotion. | Keep environments to what the promotion path needs, and automate deployments across them. |
| Data volume and index size | Larger indexes take longer to back up, verify and reindex after an upgrade, and they make rollback slower. | Set ingestion filters and retention early, and measure index growth before each planned upgrade window. |
| Custom connectors and playbooks | Custom code depends on platform APIs and GraphQL details that can change between releases and must be retested. | Keep custom code in version control, and record which platform versions each item was validated against. |
| Dependency versions (Elasticsearch or OpenSearch, Redis, RabbitMQ, S3 storage) | Each dependency has minimum versions, for example Elasticsearch 8.0 or OpenSearch 2.9, Redis 7.1 and RabbitMQ 3.11, and may need coordinated moves. | Track the documented minimums, upgrade dependencies in separate tested steps, and confirm compatibility for each target release. |
| Chosen release line | Regular releases ship daily to weekly, while LTS releases arrive every six months with one year of support, which sets upgrade frequency. | Pick one line per environment, plan fixed upgrade windows, and read the release notes before each move. |
| Enterprise Edition features (SSO, audit logs) | Since 7.260224.0, SSO strategies are an Enterprise Edition feature, and SSO and audit log settings need retesting after upgrades. | Enable only the Enterprise Edition features you need, and keep their settings documented so they can be re-checked after each upgrade. |
| Change approval strictness | Strict approval adds review time to every release, including security fixes that may need to land quickly. | Agree in advance which change types are standard, so routine releases and hotfixes follow a pre-approved path. |
How an upgrade or support engagement runs
The sequence moves an OpenCTI deployment from its current version to a chosen target with a documented inventory, a tested rehearsal, a controlled cutover and a clear handover to whoever runs it next.
Inventory the running installation
We record the running OpenCTI version, platform and worker images, every connector and its version, the Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage versions, authentication strategies, and the data volumes in each. We also confirm which edition and license is in use. The output is a written inventory that the client signs off as complete.
Choose the release line and target version
We compare the current release cadence with the LTS line and agree a target version with the client. Where the target is an LTS release, the client must hold a valid LTS license key for that line, since LTS images require one. The output is a written decision record naming the target version, the reason for it and the support window it gives.
Review connector and dependency compatibility
We check each connector and each dependency version against the target OpenCTI release, including any required search engine, Redis, RabbitMQ and storage versions, and flag anything that needs a change first. Connectors that the client builds or customizes are reviewed against the new API. The output is a compatibility matrix with an action for every item, reviewed by the client's platform owner.
Rehearse the upgrade in staging
We restore a copy of production data into a staging environment that matches production's topology, then run the full upgrade with the same connectors and workers. We measure whether workers drain queues, whether connectors write and whether the search index rebuilds as expected. The output is a rehearsal log with every issue, its fix and a go or no-go recommendation.
Cut over to production with rollback criteria
Before the change window, the client and DeployOpen agree the rollback criteria in writing, such as failed authentication, stalled worker queues or connector write errors that cannot be fixed in the window. We back up data and configuration, perform the upgrade, and follow the rollback plan if a criterion is met. The output is a cutover record showing the version now running and the backup that was verified.
Run post-upgrade checks
We verify that users can sign in through every configured authentication strategy, that each connector can write objects and relationships, and that RabbitMQ queues are consumed by the workers without growing backlog. We also confirm the API responds as expected for the client's integrations. The output is a signed checklist with results and any open items.
Hand over and set the support schedule
We deliver the updated inventory, runbook, rollback notes and known issues, then agree the support schedule, including how patches, hotfixes and the next upgrade will be handled. Support scope and response expectations are set in the written agreement. The output is a handover pack and an agreed support calendar that the client's team can run without us.
What teams keep in-house and what they outsource
This table lists the recurring OpenCTI upgrade and support activities, who usually owns each one, and the skills needed, so you can see where an internal team stops and a partner adds the most value.
| Activity | Usual owner | Skills needed |
|---|---|---|
| Reading release notes and choosing the release line | Platform owner with threat intelligence lead input | Understanding of the regular release cadence versus the LTS line, licensing, and which connectors and features a release touches |
| Maintaining the connector inventory | Connector owners in the threat intelligence team | Knowing what each feed should produce, its schedule, its credentials, and the data volume it normally creates |
| Running the staging rehearsal | Shared: partner leads the cross-stack plan, internal team validates results | Staging with production-like data, RabbitMQ and Elasticsearch or OpenSearch experience, and a written rollback path |
| Managing container image and dependency upgrades | Platform engineering or DevOps | Container orchestration, version compatibility checks for Elasticsearch or OpenSearch, Redis, RabbitMQ and object storage |
| Validating threat data after upgrade | Connector owners and analysts, with partner test scripts | Knowledge of expected entity counts, relationships and enrichment results per feed, plus STIX2 familiarity |
| Handling security fixes outside the normal window | Platform owner with on-call engineer; partner on retainer if contracted | Fast patch testing, change approval under your own policy, and the ability to deploy during off-hours |
| Daily monitoring of workers, queues and connector health | Platform engineering operations, with analysts reporting gaps | Monitoring of platform nodes, workers, RabbitMQ queues and connector run status; alert tuning |
What usually goes wrong
Most OpenCTI upgrade problems come from release choices, dependency drift and connector behavior rather than from the platform itself. The cards below name the failure points we see most often and the checks that prevent them.
Upgrading to regular releases unpinned
Regular releases ship from daily to weekly, so a production connector set that tracks the latest image can change under it without a planned window. Pin the platform and each connector to a tested version, record the exact tags, and promote a new release only after it passes in a staging copy of your connector set.
Lapsed LTS license keys
LTS releases are distributed as container images but require a specific LTS license key to use, and teams often learn this only when a pull or start fails. Confirm who holds the key, when it expires, and which LTS line it covers before scheduling any upgrade, and keep the renewal date on the operations calendar.
Treating stabilization as connector safety
The one-month stabilization period after an LTS release is not a guarantee that every connector works on it. After that period only critical bug and security fixes arrive, so test each connector you run against the candidate version and note any connector that is not yet validated.
Falling off the LTS cadence
LTS releases come every 6 months and each is supported for 1 year, so a team that skips two cycles can find its line out of support. Schedule a yearly review that compares the current LTS line with the one in use and plans the move while the overlap window is still open.
Dependency version mismatches
OpenCTI requires Elasticsearch 8.0 or OpenSearch 2.9 or later, Redis 7.1 or later, and RabbitMQ 3.11 or later. A platform release can raise the floor for these services, so compare the release notes against the running versions of each dependency before the upgrade and upgrade them in a staged order.
Connectors writing unexpected data
After an upgrade, a connector may change how it maps or deduplicates entities, which can create new objects or alter existing relationships in the knowledge graph. Compare entity counts and sample records from a connector run before and after the upgrade, and review the first scheduled imports closely.
SSO lost after moving to Enterprise Edition
Since OpenCTI 7.260224.0, defining and using authentication strategies, including SSO, requires the Enterprise Edition. Teams that move to a line that enforces this can find analysts locked out or falling back to local accounts. Export the current authentication configuration, plan the edition change, and test a login with each strategy before cutover.
No tested rollback for schema changes
Data-schema changes can make a rollback to the previous image unsafe, because the older platform may not read the migrated data. Take a verified backup of the search index and object storage, rehearse restoring it to a copy of the environment, and write down the restore order before the production upgrade starts.
How the work differs by starting point
Regular releases ship when ready, from daily to weekly, and use the x.YYMMDD.z version pattern. The work centers on a repeatable upgrade pipeline, because changes arrive often and each one needs a decision.
- Set an upgrade cadence the team can sustain and decide which releases move to staging first.
- Test each upgrade against your connectors, workers and a recent copy of production data.
- Read the release notes for dependency changes before you pull images.
- Client provides: a staging environment, a named owner who approves promotion to production, and agreed change windows.
LTS releases arrive every 6 months, each supported for 1 year, with a 6-month overlap between consecutive versions. They use the x.YYMMDD.z-lts.n pattern and require a specific LTS license key. After a one-month stabilization period, they receive only critical bug and security fixes, so features you need may only appear on the regular line.
- Confirm who holds the LTS license key and where it is stored before the plan starts.
- Plan the move onto the LTS branch and the schedule for hotfixes, which are published as numbered updates.
- Test hotfixes in staging before production, especially security fixes.
- Client provides: license ownership, an approved support window and a decision on when to move to the next LTS version.
An install that predates current dependency versions needs dependency upgrades before the platform upgrade. Current requirements include Elasticsearch 8.0 or OpenSearch 2.9 or later, Redis 7.1 or later, RabbitMQ 3.11 or later, and S3-compatible storage. A platform upgrade attempted on older dependencies can fail or leave data in a state that is hard to recover.
- Inventory the current versions of the platform, workers, search, Redis, RabbitMQ and object storage.
- Upgrade dependencies in staging, then verify indexes and queue behavior before touching the platform.
- Test index rebuilds and the drain of any queue backlog.
- Client provides: current configuration files, a verified backup, a maintenance window and access to the systems that host each dependency.
Custom or heavily modified connectors need their own compatibility tests, because platform changes can affect how connectors write data. Each connector also needs a named owner who can judge whether a change in behavior is a fault in the connector or in the platform.
- Inventory each connector with its source, owner and external API dependencies.
- Run each connector against the target release in staging and check how its records map to the STIX2 data model.
- Test deduplication and worker capacity under realistic volume.
- Client provides: connector source code, named owners, sample feeds for testing and written sign-off for each connector.
In an air-gapped or restricted network, container images must be mirrored into an internal registry and validated before deployment. Each release, hotfix and dependency update passes through the transfer process, so the plan needs time for that step and a record of what was imported.
- Mirror the images for the platform, workers and connectors, and record the image digests for each release.
- Validate images against your internal scanning and provenance policy before they reach production.
- Test each upgrade offline, including connectors that normally reach external sources.
- Client provides: an internal registry, the approved transfer process, the scanning tools your policy requires and a list of connectors permitted to reach outside sources.
What you need to provide
Before we can plan an upgrade or support scope, we need an accurate picture of what is running today. Provide the exact OpenCTI version and whether it is a regular release (x.YYMMDD.z) or an LTS build (x.YYMMDD.z-lts.n), the deployment method (container images, Helm, or other), and the versions of Elasticsearch or OpenSearch, Redis, RabbitMQ and object storage. Also list every connector with its image or version, its configuration, and the workers that run it. Connector drift is the most common reason an upgrade test fails, so this inventory is the first deliverable we need.
We also need a non-production environment that can host a copy of the platform, and a representative data set. A full copy is preferred, but if production data cannot leave its boundary, provide a sanitized sample that keeps the object types, relationships, marking definitions and volumes that your connectors and playbooks depend on. Testing against an empty instance does not show how an upgrade behaves with your data. Confirm with your data owners what sanitization is permitted before the copy is made.
Provide the OpenCTI license details for the Enterprise Edition features you use, and for any LTS line you run. Confirm with Filigran which LTS line is current and when its end-of-support date falls, using the release notes and product life cycle documentation, and confirm that your LTS license key covers the target version. Name an owner for connectors, identity and threat data quality, since each upgrade decision involves a trade-off that person must accept. Add the change window rules, approval chain and backup and restore evidence you require, including the date of your last tested restore.
Frequently asked questions
How much does an OpenCTI upgrade cost?
The cost follows from the written scope, which we agree before work starts, and we do not publish a price list. The main components are the assessment of your current version and dependencies, a staging build, connector compatibility testing, data checks, cutover, a rollback plan, documentation and handover. Labor is the largest part. Separately, you may need an Enterprise Edition or LTS license from Filigran and infrastructure for a staging environment. Cost rises with the number of connectors, data volume, dependencies to upgrade, custom code and environments. Ask for a quote that separates one-time upgrade work from any recurring support.
How long does an OpenCTI upgrade take to complete?
Timing depends on how far the current version is from the target, how many connectors and dependencies are involved, the data volume, and how quickly staging results are reviewed and approved. Your change approval process and maintenance windows also set the pace. The written scope states the schedule and the milestones it depends on. Ask for the sequence of testing, cutover and hypercare, and which steps you must complete on your side, such as access approvals and sign-off on test results.
Can our own team upgrade OpenCTI without a partner?
Yes, a team can upgrade OpenCTI itself if it has experience with containers, Linux, Elasticsearch or OpenSearch, Redis and RabbitMQ, and it has a staging environment that mirrors production. The team should read the release notes for every version in the path, restore a recent production backup into staging, and test each connector against the new platform. It also needs a verified backup, a tested rollback procedure and an approved window. Check the minimum dependency versions in the deployment overview before you start, and confirm that your license covers the target release.
Should we run OpenCTI LTS or regular releases?
Choose LTS if your team wants fewer upgrades and can test only once or twice a year. Choose regular releases if you need new features quickly and can test often. Regular releases ship when ready, from daily to weekly. LTS releases come every 6 months, each supported for 1 year, with a 6-month overlap between consecutive versions. After a one-month stabilization period, an LTS release receives only critical bug and security fixes. Your decision determines how much test effort you carry each year, so base it on your testing capacity.
Do we need an LTS license key, and what if it lapses?
Yes, OpenCTI LTS releases require a specific LTS license key to use. Confirm in writing with Filigran what happens to a running instance if the key expires, including whether the platform keeps running, whether updates and fixes stop, and what renewal or reinstatement steps apply. We advise confirming these terms before you commit to a version, because they affect your upgrade calendar and budget. We can include license checks and renewal dates in the written scope and in any support agreement.
What does ongoing support cover compared with a one-off upgrade?
A one-off upgrade covers the agreed scope: assessment, staging, testing, cutover and handover, after which the work ends. Ongoing support is a retainer that covers the items you agree in writing, such as monitoring for new releases and fixes, testing updates against your connectors, applying patches, and troubleshooting incidents. Retainers suit teams that want a partner to carry routine change work. Ask for the exact service levels and response scope in the agreement, because DeployOpen does not guarantee specific SLAs unless the written contract says so.
How DeployOpen delivers OpenCTI upgrades and support
DeployOpen plans OpenCTI upgrades as tested changes to a self-hosted platform inside your own infrastructure, covering the platform, workers, connectors and dependencies together. Support is available as a retainer once the upgrade path and operating model are agreed.
How we scope
- The written scope names your current OpenCTI version, deployment layout and target release, whether a continuous release or the LTS line.
- Scope lists every connector, worker pool, dependency (Elasticsearch or OpenSearch, Redis, RabbitMQ, object storage) and authentication strategy in use.
- Scope states which data sets, custom connectors and playbooks must be verified after the upgrade, and who approves the cutover.
How we build
- We stand up a non-production copy of your OpenCTI environment and run the upgrade there before anything touches production data.
- We test each connector and import or enrichment job against the target version and record changes in behavior, errors and data volume.
- We confirm the LTS license key requirement and dependency version compatibility with the vendor documentation before scheduling the change window.
How we hand over
- You receive an upgrade runbook with pre-checks, the ordered steps, rollback points and post-upgrade verification results.
- Configuration changes, version pins and connector updates are documented in a form your team can repeat on the next release.
- A handover session walks your operators through monitoring, log locations and the escalation path for failed workers or dependencies.
How we support
- Ongoing support is available as a retainer covering scheduled upgrades, patch review and connector compatibility checks.
- Retainer scope is agreed in writing and states response expectations, which releases are covered and what is excluded.
- Between upgrades, we review LTS hotfix and release notes against your deployment so your team knows what changes and when to act.
