Sovereign Cloud Stack R9 comes with broader usage options
Europe, 29 September 2025: Sovereign Cloud Stack Version 9 is ready
The inspiring and sold-out SCS Summit 2025 in Berlin once again clearly demonstrated that there is ongoing interest in using SCS standards and software to reduce dependencies and risks in the implementation of digital solutions, both in the public sector and in industry. For many participants, there was no question that we must work together to build open standards and open software in order to advance digitalisation while maintaining control, innovation and value creation capabilities.
The SCS community is creating a modular open source software stack that implements the SCS standards and is used in part or in whole by more than half a dozen providers to offer public or private cloud services. The technology can certainly be considered proven, having been the driving force behind public clouds for years without any unplanned outages and also providing the infrastructure for the „BayernCloud Schule“ (Bavarian Cloud School), which is accessed daily by hundreds of thousands of pupils, parents and teachers in Bavaria.
The SCS software is continuously updated. Twice a year, additional work is invested in preparing a release, reporting on progress and planning for the coming six months. The 9th version of the SCS software was also completed during the summit week.
Better hardware management
While end users have powerful standardised interfaces at their disposal for managing their virtual machines and containers, cloud operators have a more difficult task. They have to deal with hardware that tends to grow and become more diverse over time. Work on Netbox Manager has significantly improved the ability to generate configurations for this, especially for network hardware. A web interface makes it easier for operators to keep track of status and events.
Current software
On the virtualisation layer, the current OSISM-10.x now comes with OpenStack 2025.1 (Epoxy). SCS operator organisations now have the legitimate expectation that the update from the previous version will work well and be thoroughly tested. For the first time, however, a version can also be skipped, so that an upgrade is possible without an intermediate step from OSISM-8.x (with OpenStack 2024.1 Caracal), not just from OSISM-9.x (with OpenStack 2024.2 Dalmatian).
The newer OpenStack versions now support the Domain Manager role developed and contributed by the SCS community; this is a well-defined role that can be used for self-management of users and projects by customer organisations. Pass-through PCI expansion cards are now better supported, and the scenarios in which live migration is possible despite such pass-through have been expanded. This is particularly helpful for AI workloads.
The mature Ceph technology has been updated to the Reef version. Ubuntu 24.04 LTS is now used as the standard operating system on the machines, with correspondingly better support for the latest server hardware and improved performance.
The node images provided for the container solution now also use Ubuntu 24.04 LTS. Of course, the performance optimisations are also useful here. With the increasing relevance of passed-through graphics hardware for AI acceleration, hardware support may also be relevant here. And, of course, you also want to be able to benefit from the latest developments, e.g. in eBPF support, which is used by Cilium to control network traffic between containers.
The latest versions of the Kubernetes Cluster API and OpenStack Cluster API providers are included. SCS R9 comes with support for Kubernetes 1.33.x, including improvements in scalability, access token management, and pod management.
Simplified maintenance with new cluster stack
SCS Kubernetes clusters need to be able to control the underlying OpenStack cloud platform in order to create resources such as persistent storage or load balancers, and require a corresponding key to identify themselves. The duality of two different keys was consolidated, and support for proprietary certification authorities was also made easy. This change was also used as an opportunity to tidy up and systematically rename the ClusterClass parameters, which allow users to configure the cluster according to their needs. The Helm charts for the add-ons (such as CNI, CSI, CCM, Metrics) no longer need to be included, but can now be downloaded together with the container images in the appropriate version.
This simplifies the maintenance of cluster stacks. However, this is an incompatible change, which is why the new „scs2“ cluster stack series has been introduced to replace the old „scs“ series. Documentation and tools for automatic conversion will be provided shortly. The community has agreed to continuously provide the necessary artefacts that users need to apply the latest Kubernetes patches at short notice and thus ensure security.
future
The SCS community has a number of ideas for further improving the technology, e.g. in terms of performance and federation. This goes beyond incorporating the latest developments from the upstream technologies used. Many of the contributing companies are inspired and driven by their customers' requirements, e.g. the increasing number of migrations from VMware to SCS. The SCS community continues to provide the platform and well-functioning mechanisms so that these requirements can be coordinated and, if necessary, collaboration can be organised. The aim is to ensure that these improvements (and bug fixes) are easily incorporated into the shared code and can also flow back into the upstream projects. This can also go beyond the current software; software that provides an alternative implementation of the standards is also welcome to make use of these mechanisms.
In addition to openness to alternative implementations, the focus for the upcoming release will be primarily on the services and applications that run on SCS containers. Standards and software implementation will be optimised to provide an ever-improving basis for these.
