OSSEVA FOR APACHE IGNITE
Ignite 3 is a different product wearing the same name.
Apache Ignite 3 was rebuilt from the ground up — new storage engine, new client API, new SQL engine, new configuration model. It is not an upgrade from 2.x, it is a migration. Meanwhile the 2.x clusters holding production caches and compute grids keep accruing advisories.
Last reviewed
Trusted globally by enterprises
Why now
Ignite 3 is a rewrite, not a successor release
Ignite 3 replaced the storage engine, the SQL engine, the client protocol and the configuration model. Applications written against the 2.x cache and compute APIs do not port by changing a version number. That gap is why 2.x clusters are still carrying production load years into the 3.x line's existence.
Attention follows the new line, and 2.x is where the installed base is
Project energy has moved to 3.x. The 2.x series remains in extremely wide production use — in-memory caches fronting relational databases, compute grids running distributed closures, and persistent data regions holding primary copies. Widely deployed and quietly maintained is the exact combination extended support exists for.
Ignite executes arbitrary code by design
The compute grid ships user closures to nodes and runs them. Peer class loading distributes classes across the cluster automatically. These are features, not flaws — but they mean any weakness in node authentication or the discovery protocol converts directly into cluster-wide code execution, and they make an unpatched Ignite cluster a different risk profile from an unpatched cache.
Versions covered
All versions below receive active CVE patches from OSSeva. Version numbers in monospace are exact release identifiers.
| Version | Status | Active CVEs |
|---|---|---|
| 2.8.x(OSSeva patched) | EOL | Clean |
| 2.9.x(OSSeva patched) | EOL | Clean |
| 2.13.x(OSSeva patched) | EOL | Clean |
| 2.16.x(OSSeva patched) | Extended | Clean |
| 3.x(Rewritten line — upstream maintained) | Current | Clean |
What you get
Three tiers — pick the level of engagement that matches your team's operational needs and compliance requirements.
OSSeva Patch
CVE patches for Ignite 2.x with the API and storage format unchanged.
- Security backports across the 2.x line
- Discovery, communication SPI and REST advisory coverage
- Peer class loading and deserialization hardening guidance
- Maven / Docker / tarball delivery
- Signed artifacts (GPG)
- Ignite 3 migration assessment
- 24/7 managed operations
OSSeva Assure
Patch plus cluster audit and a costed assessment of the 3.x move.
- Everything in Patch
- Baseline topology and data region configuration review
- Discovery port exposure and authentication audit
- Cache and compute API usage inventory
- SOC 2 / HIPAA attestation package
- Ignite 3 migration assessment with effort estimate
- 24/7 managed operations
OSSeva Operate
Full MSP: 24/7 cluster monitoring, 15-min SLA, named Ignite engineers.
- Everything in Assure
- 24/7 heap, off-heap and baseline topology monitoring
- 15-minute P1 incident response SLA
- Named senior Apache Ignite engineer
- Checkpointing, WAL and rebalance tuning
- Migration execution to Ignite 3 or an alternative grid
- Quarterly capacity planning reviews
All tiers priced per cluster/application — not per core. Contact for pricing →
How it installs
OSSeva artifacts arrive via your existing package infrastructure. Pull the patched version the same way you pull upstream today — just from the OSSeva registry.
# Version and topology via the REST connector
curl -s 'http://ignite:8080/ignite?cmd=version'
curl -s 'http://ignite:8080/ignite?cmd=top&attr=true' | jq '.response | length'
# Discovery and communication ports. A node that can join the ring
# can run compute closures — these must not be broadly reachable.
nmap -p 47100,47500,10800,8080 ignite-node.internal<dependency>
<groupId>io.osseva.ignite</groupId>
<artifactId>ignite-core</artifactId>
<version>2.16.1-osseva-1</version>
</dependency>
<dependency>
<groupId>io.osseva.ignite</groupId>
<artifactId>ignite-indexing</artifactId>
<version>2.16.1-osseva-1</version>
</dependency>Migrate from Unsupported Apache Ignite 2.x clusters
OSSeva patches the 2.x line in place, so the cache API, persistence format and client protocol your applications were built against do not change. Where a move is warranted, the assessment costs Ignite 3 against the alternatives honestly — because a rewrite on the vendor's schedule is not automatically the right answer for your estate.
Pricing model
OSSeva for Apache Ignite is priced per cluster — not per node, cache or GB held in memory.
Frequently asked questions
Is Apache Ignite 2.x still supported?
The 2.x series still gets new minor releases: Apache Ignite 2.18.0 was announced on 6 May 2026, alongside Ignite 3.0.0 from February 2025 and 3.1.0 from October 2025. Older 2.x lines do not get patch releases. 2.13 and 2.16 each had a single release, 2.13.0 and 2.16.0, so a fix means moving to a newer minor. OSSeva ships patched builds on 2.8, 2.9, 2.13 and 2.16.
Can we upgrade from Ignite 2 to Ignite 3 in place?
No. Ignite 3 is a ground-up rewrite with a new storage engine, a new SQL engine, a new client protocol and a new configuration model. Application code written against the 2.x cache and compute APIs has to be ported, and data has to be migrated rather than read in place. It should be planned as a migration project with its own budget.
Why is an unpatched Ignite cluster higher risk than an unpatched cache?
Because Ignite is a compute grid as well as a data grid. It ships user closures to nodes and executes them, and peer class loading distributes classes across the cluster automatically. Those are intended features, but they mean a weakness in node authentication or the discovery protocol becomes cluster-wide code execution rather than data exposure.
Does OSSeva cover Ignite native persistence as well as in-memory caches?
Yes. Clusters using native persistence hold primary copies of data rather than a cache of something authoritative elsewhere, which raises both the availability and the integrity stakes. Coverage includes the persistence layer, and the Operate tier manages checkpointing, WAL and rebalance behaviour directly.
Should we move to Ignite 3 or to a different data grid entirely?
That depends on which Ignite features you actually use. If the estate leans on SQL and native persistence, Ignite 3 is a reasonable destination. If it is primarily distributed caching, other grids may be a shorter path. OSSeva covers GemFire, Geode, Hazelcast and Ignite, so the assessment compares them on your usage rather than steering toward one product.
Ready to get Apache Ignite patched and supported?
Start with a 45-minute discovery call. We confirm your version coverage, scope the engagement, and have you onboarded within your first quarter.