Stackable Data Platform 26.7: A Strategic Pivot Toward Supply Chain Integrity and Operational Maturity

In a significant departure from its established feature-driven release cadence, the Stackable Data Platform (SDP) team has unveiled version 26.7, a release that prioritizes structural integrity, security, and technical sustainability over the addition of new end-user features. For organizations leveraging the Kubernetes-native, open-source data platform, this update represents a deliberate shift toward "hardening" the ecosystem—a move designed to address the complex requirements of highly regulated industries and enterprise-grade infrastructure.

While the absence of flashy new capabilities might initially seem understated, version 26.7 delivers critical improvements to CI/CD stability, the removal of long-standing technical debt, and a rigorous overhaul of the platform’s supply chain security.

Main Facts: A Foundation for Resilient Data Infrastructure

The core mission of SDP 26.7 is to provide a more reliable, predictable, and verifiable foundation for data-intensive workloads. By focusing on stabilizing CI pipelines and purging unstable test suites, Stackable is positioning the platform to better serve mission-critical environments.

Key Technical Pillars of Release 26.7:

• Decoupled Registry Logic: The transition from hardcoded, platform-specific image registries to a dynamic, configurable architecture.
• Enhanced Security Posture: Full adoption of SLSA (Supply-chain Levels for Software Artifacts) Level 3 provenance and the integration of SPDX-formatted Software Bill of Materials (SBOMs) as OCI attestations.
• The Stackable Hub: A new, centralized, and machine-readable directory that bridges the gap between static documentation and live production state.
• Broad Compatibility: Full support for the latest Kubernetes versions (1.31 through 1.36) and Red Hat OpenShift (4.18 through 4.22).
• Vulnerability Remediation: A massive security effort that resulted in the patching of 133 CVEs, including 10 critical and 62 high-severity vulnerabilities.

Despite the focus on "under-the-hood" maintenance, the release maintains the platform’s commitment to cutting-edge open-source tooling, providing updated versions of Apache Airflow (3.2.2), Apache Superset (6.1.0), OpenSearch (3.6.0), Trino (481), Apache NiFi (2.9.0), and the Open Policy Agent (1.16.2), alongside LTS releases for Apache Spark (4.1.2) and Apache Druid (37.0.0).

Chronology and Evolution of the Platform

Stackable has consistently evolved its platform by abstracting the complexity of big data operators on Kubernetes. However, as the platform grew, the "standard path" of installation began to show friction points—particularly for users operating in "air-gapped" environments or those with highly customized internal infrastructure.

Historically, Stackable relied on a hardcoded registry (oci.stackable.tech) for all container image fetches. While this worked for standard cloud deployments, it created significant overhead for enterprise users who were forced to implement complex workarounds, such as manual mirroring or modifying containerd configurations on every node.

Version 26.7 marks the culmination of a project to move from these hardcoded defaults to a flexible, operator-driven configuration. By introducing the --image-repository CLI parameter and the IMAGE_REPOSITORY environment variable, Stackable has moved the platform logic away from the individual product level and into the cluster configuration itself. This transition ensures that operators natively understand where to pull images from, whether it be the public repository or a secure, internal private mirror.

Supporting Data and Security Compliance

For organizations in the finance, healthcare, or public sector, software provenance is no longer a "nice-to-have"—it is a regulatory mandate. The integration of SLSA Level 3 provenance and SPDX-SBOMs directly addresses the compliance requirements of the EU Cyber Resilience Act (CRA) and the NIS2 directive.

Supply Chain Security at Scale

The implementation of SLSA (Supply-chain Levels for Software Artifacts) ensures that every image shipped by Stackable can be cryptographically traced back to its origin. Using the slsa-github-generator, Stackable employs a "keyless" signing method via Sigstore and GitHub Actions as an OIDC identity provider. This prevents the possibility of a compromised build job from injecting malicious code without detection.

The Role of SPDX-SBOMs

Every container image now carries an SBOM in the SPDX format as an OCI attestation. This creates a machine-readable map of every library and component inside the container. When combined with admission controllers like Kyverno or OPA Gatekeeper, platform engineers can now implement "Policy as Code." For example, a cluster can be configured to automatically reject any image that lacks a valid SLSA attestation or one that contains a known, unpatched high-severity CVE.

The Stackable Hub: A New Centralized Directory

Perhaps the most user-facing addition is the Stackable Hub. Before this release, tracking the exact versions of components across various SDP releases required digging through Git history or navigating fragmented documentation.

The Hub provides:

1. Component Timeline: A searchable database showing exactly which versions of Kafka, Trino, or Airflow were included in any given SDP release.
2. CRD Reference: Full schema definitions for all Custom Resource Definitions, allowing developers to validate their YAML configurations without needing a live cluster.
3. API Accessibility: The Hub is built for automation. With a CORS-enabled JSON API, organizations can feed this data directly into their own CI/CD pipelines.
4. LLM Integration: By providing an llms.txt endpoint, Stackable is enabling AI assistants to access live, accurate data regarding the platform’s current state, preventing the "hallucination" of deprecated version numbers or invalid configurations.

Implications for Operators: A Breaking Change

While the architectural improvements are objectively positive, they come with a caveat: this is a breaking change.

For teams that have bypassed standard Helm or OLM (Operator Lifecycle Manager) installation methods in favor of custom deployment YAMLs, Kustomize, or ArgoCD, manual intervention is required. Users must now explicitly define the image-repository in the operator’s argument block. Furthermore, the logic for image.repository in Helm charts has been simplified—it no longer requires the operator name to be appended to the path.

Failure to adjust these parameters will result in ImagePull errors. Stackable strongly recommends that administrators perform these upgrades in a non-production staging environment to ensure their specific GitOps workflows remain intact.

Official Perspective and Strategic Direction

The move toward version 26.7 reflects Stackable’s broader strategic pivot: moving away from being "just" a collection of data tools on Kubernetes, and toward becoming a robust, verifiable platform for data sovereignty.

In discussions surrounding the release, the Stackable team emphasized that the decision to pause new features was a conscious trade-off. By clearing the "technical debt" backlog, the platform is now better equipped to scale and support the rapid adoption of AI-driven data workloads. The move to dynamic registry selection and the launch of the Hub are not merely convenience updates; they are the necessary infrastructure for a world where "Software Supply Chain Security" is the primary barrier to entry for enterprise-grade open-source adoption.

As the industry moves toward the requirements of the EU Cyber Resilience Act, Stackable is positioning itself as a leader in transparency. By providing the tools for operators to verify every line of code and every image source, the company is effectively lowering the barrier to compliance for its users.

Conclusion

Stackable Data Platform 26.7 is a "boring" release in the best possible way. It does not introduce new bells and whistles that require re-learning the platform. Instead, it provides the structural fortitude that large-scale organizations demand. By prioritizing the stability of CI pipelines, the security of the software supply chain, and the accessibility of platform metadata, Stackable has set a new standard for how open-source data platforms should evolve in an era of heightened security scrutiny.

For current users, the update is a call to audit their deployment manifests and embrace the new, more flexible registry configuration. For those watching from the outside, 26.7 demonstrates that Stackable is playing the long game—focusing on sustainability, interoperability, and the technical maturity required for the next generation of data-driven enterprises.