The X-Road 8 “Spaceship” development continued fully during the first half of 2025, even though the previous status update was published in December 2024. Regardless of the pause in X-Road 8-related blog posts, we haven't been resting on our laurels. Monthly status updates are also available in the X-Road Community Expert Group meeting minutes.
This blog post explores what has happened in the X-Road 8 development during the last six months.
Starting the production-level implementation
In 2024, we implemented a PoC which verified that X-Road could be transformed into a data space technology in a backwards-compatible manner. That included experimenting with different approaches and solutions, which caused the PoC deliverables to be less optimal as the basis of a production-level implementation. Therefore, we decided to kick off the production-level implementation by taking the latest X-Road 7 release version (X-Road 7.6.0 at the time) as a basis and start implementing the required changes on top of it. In practice, the X-Road 8 development on GitHub was moved from the edc-poc branch to the develop-8.x branch.
We decided to work with the production-level implementation in multiple phases. First, we start with the changes to the existing X-Road architecture and implement improved support for containers. In addition, the visual layout of the Central Server and Security Server UIs will be updated according to the X-Road 8 visual style guide. Then, after refactoring the foundation, we add support for the data space protocol stack and the Gaia-X Trust Framework. In this way, we avoid implementing too many significant parallel changes and focus better on the ongoing tasks. So far, this has proven to be a good choice.
Better support for containers
In X-Road 7, the Security Server already supports containerised deployment, but the current implementation has certain limitations. For example, all the Security Server modules are deployed to a single container, and splitting them into multiple containers is not supported.
In X-Road 8, different Security Server modules will be deployed to separate containers, enabling more flexible deployment and scalability options. Now, the Security Server containerisation has reached the point when it's possible to run a Security Server instance consisting of multiple containers:
Configuration Client
Proxy
Signer
Proxy UI API
Backup Manager
Environmental Monitoring
Operational Monitoring
Messagelog Archiver
Open Bao
Running the Security Server will require an external database since the database is not included in the X-Road 8 containers. The external database can be a separate database container or some managed database service in the cloud. The setup can be orchestrated using Kubernetes-based container management tools, e.g., k8s. Nevertheless, the containerisation-related work has not yet been completed since there are still open questions that need to be resolved.
Supporting Kubernetes for containerised deployments
The aim is for the containerised version of X-Road 8 to be deployed on various container orchestration platforms. However, implementing fully automated backup and restore requires that the X-Road application is able to interact with the orchestration platform via its APIs to manage the application containers. Unfortunately, there are no unified standards for the APIs, and therefore, each platform has its own implementation, e.g., stopping and starting containers is handled differently by Kubernetes and Docker Compose.
Supporting fully automated backup and restore process requires including container orchestration platform-specific details in X-Road's implementation. Since Kubernetes is the most widely supported container orchestration platform and there are several Kubernetes-based services and products available (e.g., Kubernetes (K8s), Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE), Red Hat OpenShift), it has been chosen as the orchestration platform supported by X-Road 8. This means that even if the X-Road Docker images can be run anywhere, there are Kubernetes-specific features that will limit X-Road's ease of use with other orchestrators. For example, deploying the Security Server using some other orchestrator is possible, but the application-level backup/restore features are unavailable, and the administrator must implement the backup/restore using different tools.
Improvements to the signer's scalability
The signer is currently one of the Security Server's known performance bottlenecks. Therefore, the signer architecture and source code have been refactored to improve performance.
The signer has been made more modular by separating signer management and processing signing operations. Signer management is always run in a single instance, and multiple instances can perform signing operations. Nevertheless, it's still possible to run a single signer instance that's responsible for both management and signing. In addition, the implementation has been refactored to allow multiple parallel non-modifying operations (e.g., signing messages) while only one operation at a time was allowed before.
When we started working with X-Road 8, most of the signer code was from 2014-2015, when X-Road 6 was implemented. During the X-Road 8 implementation project, over 30% of the signer code has been changed, and more changes are expected until the work is completed. The new implementation is expected to improve the signer's performance and contribute positively to the overall performance of the Security Server.
Changes to the Security Server add-ons
The Security Server supports add-ons that provide additional features on top of the core functionality, e.g., message logging and environmental and operational monitoring are all Security Server add-ons. In X-Road 7, add-ons are implemented as separate add-on packages that can be installed separately. In X-Road 8, separate add-on packages will be removed, and all add-ons will be packaged with the Security Server core. In this way, Security Server administrators can turn add-ons on/off by updating Security Server's configuration instead of having to install/remove packages. The change simplifies managing add-ons and enables using the same approach in add-on management regardless of the Security Server deployment model (native / container).
Moving configuration data to the database
In X-Road 7, configuration data is stored in the filesystem (e.g., /etc/xroad) and the database. This means that the backup and restore processes must be able to access both locations. It is not an issue when all the components run on the same host and share the same file system. Instead, the situation becomes more complicated when different components are not deployed together, and the configuration files included in the backup don't reside on the same file system. For example, this is the case with X-Road 8 containerised deployment, where every component is deployed in a separate container.
All the possible configuration data is moved from the filesystem to the database to simplify the backup and restore process of the containerised deployment in X-Road 8. This includes configuration properties, signer data, keys, configuration anchor file, etc. Also, PostgreSQL is used as a storage backend for locally deployed OpenBao (OpenBao is used as a secure secret storage in X-Road 8). In this way, the backup of the containerised deployment consists only of the database dump. Instead, in the native deployment, the backup still includes configuration files from the /etc/xroad folder.
New Backup Manager module
In X-Road 8, all the backup and restore-related logic is moved to a new Backup Manager module. The module is present in all deployment types (native, containerised), but the implementation of different operations (e.g., backup, restore) varies between them. For example, in containerised deployments, only configuration data from the database is backed up, while in native deployments, specific configuration files are also included. The module exposes gRPC endpoints for the Admin UI module to trigger backup/restore processes.
In addition, other backup-related tasks that were earlier implemented in different modules have been moved to the Backup Manager module. For example, automatic backup creation has been moved from the Configuration Client module, and automatic removal of old backup files has been moved from the Proxy module.
What about data spaces?
As mentioned earlier, during the first half of 2025, our primary focus has been implementing changes to the existing X-Road architecture. However, that doesn't mean we've forgotten data spaces or haven't been following the latest developments in different data space initiatives. NIIS is a member of the Gaia-X European Association for Data and Cloud AISBL, International Data Spaces Association (IDSA) and Eclipse Dataspace Working Group (EDWG), which makes it an active participant in various data space activities. Also, the goal regarding X-Road and data spaces hasn’t changed – to transform X-Road into a data space technology in a backwards-compatible manner and make X-Road technically interoperable with the Gaia-X Trust Framework.
Meanwhile, different data space-related protocols are evolving and getting closer to their release versions. The Data Space Protocol (DSP) and Decentralised Claims Protocol (DCP) by the EDWG are estimated to reach release version 1 in H2 / 2025. Instead, the DSP submission to become an ISO standard is scheduled for Q4 / 2025. The Eclipse Dataspace Components (EDC) project will implement both protocols, and it's expected to provide a stable implementation of DSP and DCP release version 1 in Q4 / 2025. The schedule is well aligned with the X-Road 8 development since the stable EDC version should be available by the time the X-Road architecture-related changes have been completed.
In addition to DCP, there’s also another protocol for issuing and sharing verified credentials that can be used in the context of data spaces - the OpenID for Verified Credentials (OID4VC) protocol. In the data space community, there’s an ongoing discussion about the protocols and their use for different use cases in various data space initiatives. The current plan is for X-Road 8 to use the DCP protocol for issuing and sharing verified credentials since the support comes with the EDC. In addition, the aim is to support the OID4VC protocol for verified credentials issuance. Nevertheless, we're actively following activities related to the topic and are ready to review and update our plans if needed. For X-Road 8, the main goal is to be interoperable with different data space initiatives and enable cross-data space interoperability.
What’s next?
All in all, the development of X-Road 8 is progressing nicely, and we're on track to publish the first production version of X-Road 8 "Spaceship" in 2026, as planned.
Currently, we’re in the first phase of our implementation plan—implementing changes to the existing X-Road architecture. We have also just started to work on updating the Central Server and Security Server UIs according to the X-Road 8 visual style guide. This means that the implemented changes become more visible to the X-Road users since they’re not only about technical and architectural changes under the hood anymore. We expect the current development activities to continue at least until Q4 of 2025. After that we will continue to the second phase - add support for the data space protocol stack and the Gaia-X Trust Framework.
The X-Road 8 beta version will be published in Q4 / 2025. It will include all the architectural changes implemented until then and updated UIs with a new look and feel aligned with the X-Road 8 "Spaceship" visual style. The beta version will allow for testing the Security Server's new, more modular architecture and a new approach to containerised deployments in practice. We would like to receive feedback about the changes from the community to ensure that the implemented changes align with the community's needs and expectations.
Instead, the beta version will not include new data space-related features yet. Their implementation may start before the beta is released, but it's unlikely they will reach sufficient maturity to be included in the beta. An updated version of the beta—or beta 2—will be released sometime in 2026 so that the X-Road community can test new data space-related changes in practice before the first production release.
More blog posts about X-Road 8 will follow later this year. Stay tuned!