Technical Committee


The Technical Committee is responsible for all technical matters relating to the purpose of the Association. It decides on the Technical Architecture, the Architecture of Standards and the Open Source Software Portfolio, including the Federation Services. It manages the inputs from the work packages, coordinates demonstrators and use cases.

flowchart BT; WorkingGroups --> tc[[Technical Committee]] WorkPackages --> wgn subgraph WorkingGroups wg1[Working Group 1] swg1[Sub-Working Group 1] --> wg1 wg2[Working Group 2] wgn[Working Group N] end subgraph WorkPackages wp1([Open Work Work Package 1]) wp2([Open Work Package 2]) swp2([Sub-Working Group 1]) --> wp2 wpn([Open Work Package N]) end

Working Groups

All Working Groups' deliverables must be stored on one of the Gaia-X platforms. See the Tools section (DCP, Gitlab, ...)

The Working Groups report to the Technical Committee.

Federation Services WG

The Federation Services are specified by this Working Group. It coordinates the development of the services as an open source software project. It aligns all activities with the corresponding policies. It facilitates the Architecture Decision Record and summarises the decisions for the Architecture of Standards.

The Federation Services/OSS Working Group shall consist of Members which drive forward the GAIA-X Federation Services (GXFS), maintaining the GXFS and coordinating the corresponding open-source repositories.


Evolution Federation Services (functional)
  • Requirements of WG User/ WG Provider/ Data Space Committee perspective
  • Requirements by Hubs
  • Roadmap for evolution of FS specifications
Operation of Federation Services
  • Security DevOps
  • Definition of Federator
  • Requirements for offering FS (accreditation etc.)
  • Busines model for Federators / include WG Portfolio/others
  • Interaction of Federations


GXFS Services and related Standards, based on ADRs


  • Andreas Weiss
  • N.N.

Place of documentation



flowchart BT subgraph WorkingGroup wgfed[Federation Services] click wgfed "" end subgraph WorkPackages wpcatalog([Catalogue]) wpsd([Self-Description]) wpportal([Portal & User Interface]) wpmvg([Minimum Viable Gaia-X]) wpcompliance([Compliance]) end WorkPackages --> wgfed prc[[Policy Rules Committee]] -.- wpcompliance

Architecture WG

This Working Group defines, develops, and governs the Technical Architecture, which is defined within the “Architecture of Standards” (AoS) of Gaia-X. It ensures architectural integrity and consistency, controls the quality and assesses the proposals and interconnections across the whole project.

The Architecture TC Working Group shall consist of Members to elevate, create and provide oversight of the Gaia-X Architecture of Standards, including, but not limited to the specification of the related Application Framework for interaction with the GAIA-X Federation Services.


The Architecture Working Group is responsible for:

  • Definiton, development and governance of Technical Architecture and “Architecture of Standards” (AoS) of Gaia-X
  • Architectural Integrity and Consistency
  • Quality Control and Assessment of Technical Proposals and Interconnection across all requirements, working packages and community projects to ensure architecture compliance
  • Maintaintenance of the scope of the Gaia-X Architecture


  • Technical Architecture Document (incl. Metamodel and I/F description),
  • Architecture of Standards, Description of the Architecture governance and compliance processes
  • Change Management: ADR Process


  • Klaus Ottradovetz
  • Christian Weiss

ADR process

Is documented in this GitLab Wiki

Gitlab permissions

By default, the Architecture document repository is accessible only to all Gaia-X members.

At the moment, every member has to request access and will be by default granted Reporter permissions.

Any member can submit a proposal via the creation of a Merge-Request, via a fork - like in a git process. Any member can comment on any existing Issue and Merge-Request

Only the members of the Technical Committee and the WG Architecture have the Developer permissions and can edit/approve/reject merge-requests.


flowchart BT subgraph WorkingGroup wgarch[Architecture] end subgraph WorkPackages wpaos([Architecture of Standards]) wpiam([Identity & Trust]) wpdata([Data Sovereignty]) wpinterconnec([Interconnection]) wpinfra([Infrastructure]) subgraph Infrastructure wpstorage([Storage]) --> wpinfra wpnetwork([Network]) --> wpinfra wpcompute([Compute]) --> wpinfra end wpinterconnec -.- Infrastructure end WorkPackages --> wgarch

X-Association WG

This working group establishes links with other associations, initiatives and projects and thus identifies potential cooperation partners. It is the contact point for organisations interested in cooperation. It discusses the interoperability of Gaia-X with them and plans a joint roadmap. If this results in new requirements for Gaia-X, it passes this information on to the relevant working group.

The X-Association Working Group shall consist of Members, as well as of representatives of other formally liaised associations (who are not Members of the Association) to elevate and represent their associations' requirements to the standard. This group is the contact point for organizations interested in cooperation with the Association.


  • Gateway for liaisons with other Associations, initiatives and projects
  • Identify potential cooperation partners and prioritize them
  • Contact point for organizations interested in cooperation
  • Interact with other organizations to discuss interoperability and joint roadmap planning
  • Make suggestions to roadmap according to these liaison discussions
  • Generate new or detail existing requirements for GAIA-X or from GAIA-X to others

Deliverables (output):

  • GAIA-X Liaison Strategy document
  • List of potential Liaison partners
  • List of active Liaison partners
  • Assessment of potential and active Liaison partners
  • Standardization and Liaison roadmap


Sebastian Steinbuss

Regular meeting date and time:

Fridays from 13 to 14

flowchart BT subgraph WorkingGroup wgxass[X-Association] end subgraph Associations fiware[/Fiware/] idsa[/IDSA/] bdva[/BDVA/] more[/.../] end Associations -.- wgxass

Portfolio WG

This Working Groups develops and governs the Gaia-X Portfolio. In doing so, it develops the value proposition for Gaia-X service providers and customers. With this value proposition, the Working Group positions Gaia-X within the project and in the public domain. It derives portfolio requirements and solution approaches, developing a roadmap based on the requirements of consumers, providers and the Technical Architecture of Gaia-X.

The Portfolio Working Group shall consist of Members to develop and govern GAIA-X portfolio management processes, develop and maintain the GAIA-X product roadmap based on user, provider and architecture requirements and the GAIA-X value proposition. The Portfolio Working Group shall develop the GAIA-X value propositions for GAIA-X service providers and customers of GAIA-X Service Providers and communicate the value proposition statement inside and outside of GAIA-X.


  • Develop and govern the Gaia-X portfolio management process
  • Develop Gaia-X value propositions for Gaia-X service providers and customers of GAIA-X Service Providers
  • Position value proposition statement inside and outside of Gaia-X
  • Derive portfolio requirements and solution concepts
  • Develop and maintain Gaia-X Product roadmap based on consumer, provider and architecture requirements

Required prerequisites (input):

  • Input from the GAIA-X community
  • Strong collaboration with WG User, WG Provider, DataSpaceBusiness Committee and PolicyRules Committee

Deliverables (output):

  • Gaia-X product roadmap
  • Gaia-X value proposition statement
  • Gaia-X portfolio management process and roadmap


  • Michael Jochem
  • Mark Kühner

Regular meeting date and time:

Wednesdays from 15:30 to 16:30

flowchart BT subgraph WorkingGroup wgportf[Portfolio] end subgraph WorkPackages wppsb[Product & Service board] end WorkPackages --> wgportf

User WG

This Working Group works with the Hubs to check that the work of the Data Spaces and the use cases are in line with Gaia-X objectives. It structures the requirements from the consumers of data, services and infrastructure and prioritises them. The members of the Working Group regularly exchange information with the hubs about their experiences and the implementation of Data Spaces.

The User Working Group shall consist of Members, who shall carry the scope of user requirements for the Association and interact with the various user domains of the Gaia-X hubs to elevate and represent their user requirements to the standard.


  • Be the User Success Advocates as representatives of Data Spaces with the Technical Committee
  • Bring the perspective of Data Controllers (owning the responsibility of data in data-sharing Use Cases)
  • Build the bridge with the Technical Stream of the Data Space Business Committee
  • Work with Data Spaces, Data Space Business Committee and with the User Hubs organization to:
    • Collect documented Data Spaces definitions and/or Domain Use Cases (with their expected business value)
    • Check that Data Spaces requirements and priorities (express or implied) are consistent with what GAIA-X is organizing to deliver as a Product
    • Structure/prioritize requirements from data, services and infrastructure consumers and transfer them into a prioritized list of RfCs
    • Deploy guidance and foster experience sharing regarding how to implement Data Spaces with Gaia-X

Required prerequisites (input):

  • From the Architecture Working Group, it will be expected to receive (as the GAIA-X Project matures and this becomes timely feasible):
    • For Data Space High-Level Technical Design: Deployment scenarios and reusable technical architecture patterns / templates
  • From the Federation Services/OSS Working Group (same – as this becomes timely feasible):
    • For Data Space Detailed Technical Design: Federation Services Specification / API Framework

Deliverables (output):

  • User requirements
  • Requests for Change
  • New community project proposals or initiatives

Member criteria:

  • Legitimacy: representative of a Data Space, as the owner of Use Cases and/or nominated by Data Space Leadership
  • Operational delivery skills: experience in IT Architecture and/or Project Management (Business Analysis and Data Modeling are a great plus)
  • Availability: each member should expect potentially between 20 and 50% of their time necessary and available for GAIA-X
  • Persistence over time and continuity of presence in the Working Group


  • Stefan Ettl
  • Stephan Stryhanyn

Regular meeting date and time:

Mondays from 9 to 10

Place of documentation:

Onboarding Questions:

  1. Why do you think your organization and this person together fit the User WG Charter, key objectives, and member requirements?
  2. Which Data Space are you a representative of (as the owner of Use Cases and/or nominated by Data Space Leadership)?
  3. Does your company/organization’s position in Gaia-X qualify as a Data Controller? Why?
  4. What are your key objectives when joining the WG User?


flowchart BT subgraph WorkingGroup wguser[User] end dsbc[[Dataspace & Business Committee]] -.- wguser hub1[[Hub FR]] -.- dsbc hub2[[Hub DE]] -.- dsbc hub3[[Hub IT]] -.- dsbc hub4[[Hub ...]] -.- dsbc

Provider WG

This Working Group defines the requirements for the Technical Architecture for Gaia-X, the Architecture of Standards, Policy and Rules and the Federation Services. Therefore, it structures the requirements from the providers and prioritises them. It suggests implementation projects and initiatives. Finally, the Working Group is developing the provider ecosystem and a provider community.

The Provider Working Group shall consist of Members, who shall carry the scope of provider requirements for the Association and elevate and represent their provider requirements to the standard.


  • Create and maintain requirements for Gaia-X building blocks like the Technical Architecture, AoS, Policy and Rules, Federation Services
  • Structure/aggregate/prioritize requirements from data, service and infrastructure providers and transfer them into a prioritized list of RfCs
  • Suggest implementation projects and initiatives
  • Develop the provider ecosystem and a provider community & measure
  • Increase the ability of providers to participate in the Gaia-X ecosystem and provide valid input for the definition of Self Description templates.
  • On the basis of the collaboration with the other working groups, improve the ability to respond to sector-specific customers’ needs
  • Enhance interoperability between providers
  • Raise customer awareness about the added value of GAIA-X and try to involve them in building use-cases
  • Contribute to the development of Regional Hubs

Deliverables (output):

  • High-level enablers and blockers for Gaia-X from a technical, legal and business model perspective (“What do providers want and fear?”)
  • Long-term and short-term expectations for Gaia-X (input for WG Portfolio)
  • Requirements document from a provider view as a continuous deliverable
  • Provider engagement initiatives (e.g., conferences, webinars)
  • Level of engagement and adoption among providers and reasons for inadequate numbers
  • Functional and non-functional provider, node, and service self-description attributes
  • Guidelines on how to implement and increase, as providers, sector-specific compliance
  • Concrete examples of organizational, semantic and technical interoperability


  • Anja Strunk

Regular meeting date and time:

Mondays from 13:00 to 14:00

flowchart BT subgraph WorkingGroup wgprov[Provider] end subgraph WorkPackages wpscs[Sovereign Cloud Stack] end WorkPackages --> wgprov

How to join a Working Group ?

Get in touch with the staff facilitating the working groups:
- through the Talk feature on the DCP (write to WG-Support)
- through an e-mail to the mailing-list

Criteria to become a participant in a TC Working Group:
1. AISBL Membership of the organization the applicant is working for
2. No further participant in the specific WG out of organization the applicant is working for

Additional, specific criteria apply for the specific working groups (tba).

Open Work Packages

The open-source Gaia-X Community comprises the entire, global Gaia-X network. Users and providers collaborate on Open Work Packages. Everyone is welcome to join the Community and contribute to the establishment of a federated data infrastructure.

The Open Work Packages are community-driven projects initiated by contributors outside the Gaia-X Association. With an elected chair and co-chair, Open Work Packages can choose their own organisational structure.

The Technical Committee plays a supervisory role in the assignment and steering of the Open Work Packages, ensuring that their outputs – whether in the form of position papers, technical evaluations, code, whitepapers or proposals – are integrated into the technical development of Gaia-X. Therefore each Open Work Package is associated with a Working Group of the Gaia-X Association. To be associated with the Gaia-X Association an Open Work Package must have a lead and optional co-lead, a clear description of their scope and an identified Gaia-X Association Working Group which they are associated with for close coordination.

Typically, an Open Work Package also meets regularly (weekly). The Gaia-X Association offers mailing lists for all established Open Work Packages for the purpose of coordination and self-organization.

A overview of Open Work Packages can be found below.

To join a Open Work Package visit and subscribe to the respective mailing-list. Be aware that not following invitations to WP meetings and not contributing to the progress of the WP can result in cancelling your subscription, i. e. your participation in the WP.

How to create a new Open Work Package

A Open Work Package must fullfill some key requirements:

  • Must have a lead. Optionally, could have a co-lead.
  • Must have a clear and public charter description
    • Scope description
    • Expected deliverables (see Deliverables section below)
    • Out of scope description
    • A contact point (See Mailing-list in the Tools section)
  • Must have a clear and identified Working Group parent.
  • Must have a written (email) approval of above items by the parent Working Group lead.

OWP Catalogue

The Federated Catalogue is a logical combination of a Self-Description repository and search algorithms so that Self-Description-based attribute searches can be processed.

Every Asset must be registered in GAIA-X Federated Catalogues. The basis for this registration is the Self-Description which must be provided by the previously registered GAIA-X Provider.

Self-Descriptions in a Catalogue are either entered directly by the respective Provider, imported from another federated GAIA-X Catalogue or even imported from an external collection.

A Catalogue can represent different views on existing offerings, such as domain-specific selections of Assets. This feature will be helpful as long as the Consumer is aware and able to switch off any catalog restriction in a simple way and get access to all offered Assets.

The WP will focus on the development of the necessary concepts to realize the idea of a federated catalogue. The work is strongly related to the WPs "Data Broker/ Data Connector", “Self-Description”, “Continuous Monitoring” and “IAM Policy and Rules”. Therefore the demands like the necessary service attributes mentioned by the self-description, the continuous fulfilling of GAIA-X compliance standards by the services or the access control of the data, will be elaborated.

OWP Compliance

The Open Work Package elaborates a draft concept for Gaia-X certification process. Certification refers to neutral attestations of systems (i.e., Gaia-X Services and Nodes) and related management operations and that verify the conformity of those systems and operations to pre-specified certification requirements (i.e., in regard to data proception or IT security). The Open Work Package defines the certification objects, the technical layers to be certified as well as the scope of the certification, which includes requirements for Interoperability & Portability, performance requirements as well as sector-specific requirements. The conceptualization of the certification process aims to prevent duplicate certifications and reduce efforts. Therefore, existing certifications and standards are recognized.

The Open Work Package proposes a process for the initial registration of providers and their respective services and nodes in the Gaia-X environment, which is referred to as on-boarding of providers (Accreditation). The goal is to design an on-boarding approach which assures a level of conformity adequate to the Gaia-X principles but allows also for organizations with limited resources (SME, Start-ups) to enter the Gaia-X ecosystem. This implies that on the Gaia-X repository level (i.e., the Gaia-X platform) a clear and unambiguous indication of the level of assurance for each service/node has to be provided to allow for the customer to take an informed decision as to which service/node and the respective provider match her individual preferences. Minimum requirements for the onboarding of nodes - referred to as basic levels of assurance - are defined as well as optional requirements elaborated. Currently out of scope is the offboarding /deregistration process.

The Open Work Package also aims to define facilities and requirements for establishing Continuous Monitoring for all Gaia-X infrastructure components, referencing candidates (elements/entities) of Self-Description. Monitoring in the context of Gaia-X refers to the access to status information of Services and Nodes, as well as alerting. Monitoring is essential for the operation of large-scale distributed applications. Gaia-X will define standard mechanisms and interfaces for monitoring.

OWP Cross-Environment Service Orchestration (CESO)

The Open Work package “Cross-Environment Service Orchestration“ aims to serve the following purpose:

  • Broadly distribute the survey on the tools currently used for service composition and on the knowledge and evaluation about the use of TOSCA
  • Evaluate the results of the survey
  • Increase Providers' knowledge of TOSCA
  • Define the applicability spectrum of TOSCA for service composition in Gaia-X
  • Identify the implementation of TOSCA to be used
  • Define a model to connect Self Descriptions and TOSCA (integrate all relevant areas of TOSCA into Self-descriptions/integrate a link within the self-description to a TOSCA configuration file)
  • Define and test the application of TOSCA for different areas (IaaS/SaaS/Networking/FaaS/edge)
  • Evaluate and if possible develop the application of TOSCA for data provision services
  • Contribute to the organisation and participate in the TOSCA hackathon (led by OWP MVG)

Deliverables of the OWP Cross-Environment Service Orchestration:

  • A confirmation of the applicability of TOSCA as a tool for composition and automation of service deployment in Gaia-X
  • A model to connect Self-Descriptions and TOSCA
  • Testing for the application of TOSCA for combining a large set of Gaia-X services
  • A widespread and uniform level of knowledge of TOSCA among Providers

OWP Infrastructure

The OWP “Infrastructure” aims to envision open sovereign infrastructure standards, to drive infrastructure standardization across the European infrastructure ecosystem and to deliver an open infrastructure reference for Gaia-X. It further seeks to provide a community forum around sovereign infrastructure for Gaia-X. WG Infrastructure is supported in its endeavour by four sub Work Packages: data center, network, storage, and compute.

Data Center


  • Provide considerations for Data Center (“Gaia-X Data Center”) infrastructures suitable for the needs of Gaia-X
  • Define the term “Data Center” with regard to Gaia-X
  • Suggest mandatory and optional self-description attributes for Data Centers in Gaia-X infrastructures
  • Consider and promote EU Regulations on data centre sustainability and integrate them into the Framework
  • Emphasize the need for Standards and Regulations around data centre security / safety
  • Provide a forum for collaboration between the various actors within the data centre community to contribute towards Gaia-X data center reference infrastructures
  • Enhance the cross collaboration between the Gaia-X data centre community and the wider Gaia-X infrastructure community and WGs and WPs (Provider, SCS, and others)
  • Promote and consider established and upcoming industry standards in the data centre domain & also other European Communities looking into data centre infrastructure



  • Provide a network (“Gaia-X network”) reference architecture suitable for the needs of Gaia-X infrastructure
  • Identify and assess various architectural considerations for building an open data centre network infrastructure
  • Help drive infrastructure, interoperability, interconnectivity and security
  • Provide a forum for collaboration between the various actors within the networking community to contribute towards Gaia-X network reference architecture
  • Enhance the cross collaboration between the Gaia-X network community and the wider Gaia-X infrastructure community and WGs and WPs (Provider, SCS, and others)
  • Support adoption of open source networking technologies (when and where possible)
  • Foster links and aggregate possible works from the community and the wider networking ecosystem with respect to evaluating suitability for Gaia-X networking ecosystem with respect to evaluating suitability for Gaia-X network reference infrastructure
  • Promote (possibly multiple) reference implementations adhering to the Gaia-X



  • Provide a data storage and low level data management (“Gaia-X storage”) infrastructure reference architecture/demonstrations/POCs suitable for the needs of Gaia-X Infrastructure
  • Identify and assess various architectural considerations for building an open sovereign data storage & low level data management infrastructure
  • Provide inputs to Self Description
  • Help drive data storage and low level data management infrastructure interoperability
  • Provide a forum for collaboration between the various actors within the storage and low level data management community to contribute towards Gaia-X storage reference
  • Enhance cross collaboration between the Gaia-X storage community and the wider Gaia-X infrastructure community and WGs and WPs (Provider, SCS, and others)
  • Foster & promote links with other standardisation bodies in storage domain (SNIA, and others) & also other European Communities looking into storage infrastructure
  • Support adoption of open source storage technologies (when and where possible, primarily in the area of storage infrastructure software)
  • Foster links and aggregate possible works from the community and the wider storage ecosystem with respect to suitability for Gaia-X storage reference infrastructure
  • Promote (possibly multiple) reference implementations adhering to the Gaia-X Infrastructure


  • The sub Work Package Compute is still inactive.

OWP Interconnection & Network

Enable interoperability and interconnection of infrastructure, applications and data across service providers, thus supporting GAIA-X's central goal of free-flow of data.

This requires GAIA-X to align network and interconnection providers, bare metal providers, Cloud Solution Providers (CSP), High Performance Computing (HPC) as well as sector specific clouds and edge clouds. Here, mechanisms are developed to find, combine and connect services from participating providers in order to enable a user-friendly infrastructure ecosystem. The mentioned services rely on a physical infrastructure like data centres, the respective hardware as well as the interconnection/networking.

The focus of this group is to provide self-descriptions for numerous interconnections and networking services required by Use-Cases. In order to do so, the topic of network service composition is the current focus of this group

OWP Data Exchange Interoperability


Enabling Data Exchange Interoperability in Gaia-X - Define how multiple existing Meta Models and formats for data exchange can be made interoperable
- Combining data brokerage and data end points
- Align with existing concepts (IDS, AAS I4.0, Health Server,…)
- Technical connection on protocol level and semantic interop (business and tech Meta-data description)

Required prerequisites (input):

Integration of various external standards (to be defined during work)

Deliverables (output):

  • Create prototypes / PoCs for such interoperable machines
  • First draft to describe data availability, service options; sovereign data exchange and networking requirements
  • Listing of possible services (on general level)
  • Listing of available standards for interconnection
  • First Implementation Planning

OWP Minimal viable Gaia-X

The Open Work Package “Minimal Viable Gaia-X (MVG)” aims on the development of a minimal viable Gaia-X as a community-driven demonstrator project, which elaborates rationales of identified control points (Federation Services) of Gaia-X ecosystem. It describes minimal requirements for the operation of all Gaia-X Use Cases, the value add of Gaia-X and the technical architecture, which are necessary to build and develop a trusted environment between partners and interoperable links between smart service applications, dataspace and infrastructure services. The focus of the Open Work Package Minimal Viable Gaia-X is twofold:

1) Keeping an overview of the Gaia-X Federation Services, Technical Architecture and Architecture of Standards plus synchronizing and spreading knowledge about the Gaia-X Federation Services, Technical Architecture and Architecture of Standards implementation state within the community.

2) Providing a forum for pitching Gaia-X-based projects leveraging the Gaia-X Federation Services and discussing the progress of these projects.

As both aspects are related to the Gaia-X Federation Services, Technical Architecture and Architecture of Standards development, the discussions during the call shall help to push forward the Gaia-X Federation Services, Technical Architecture and Architecture of Standards design and implementation by fostering the application and instantiation of the Gaia-X Federation Services, Technical Architecture, and Architecture of Standards.

OWP Self-Description

The OWP „Self-Descriptions (SD)“ aims to specify how Gaia-X entities (participants, assets, recources, service offering,…) shall describe themselves and how these Self-Descriptions are managed (versioned, queried,…) in a Federated Catalogue. Therefore, it seeks to develop the ontology (vocabulary/schema/information model) for the Self-Descriptions covering the structure of the entities, relationships such as dependencies, and a set of common attributes. WP Self-Description seeks to deliver best-practice examples of Self-Description instances/templates, Self-Description management tools, and documentation of Self-Description/Ontology development workflow and to provide a forum for collaboration between the various actors within the and enhance cross collaboration between the Gaia-X self-description community and the wider Gaia-X community and WGs and WPs.

Deliverables of the OWP Self-Description:

  • Conceptual foundations, meta model, and requirements
  • Self-description architecture and ontology
  • Initial set of self-description attributes
  • Self-description life cycle
  • Validation and certification process

OWP Sovereign Cloud Stack

The OWP “Sovereign Cloud Stack (SCS)” aims to create a network of open source IaaS/CaaS/PaaS providers to together define and implement a fully open source, modular and complete software stack. To this aim, WP SCS joins forces also in operational topics („Open Operations“ as extension to „Open Source“) by documenting and sharing operational best practices and operational tooling (lifecycle management, CI/CD, monitoring, logging, automation,…). Provide a reference environment to validate GXFS and other constitutional GAIA-X deliverables and a complete standard and software stack to deliver sovereign infrastructure services for GAIA-X.

The deliverables of the OWP Sovereign Cloud Stack:

  • A complete open source modular software stack for providers (internal and public) to deliver Gaia-X compliant IaaS, CaaS and PaaS services (on top of commodity hardware)
  • The stack covers network/storage/compute virtualization, infrastructural software, operational tooling, IaaS, Kubernetes as a Service (incl. Tooling and CSI/CNI) and (perspectively) a set of standard platform services (PaaS).
  • Operational tooling (automation, monitoring, lifecycle management, CI/CD, ...) and Operational Best Practices (Documents)
  • Certifiable standards along with conformance tests
  • Several SCS based platforms that are fully compatible (conforming to SCS standards) and can be federated
  • Self-descriptions for these platforms


Common expectation for all Groups

The commonn expectation are:

  • to output documents, position papers, propositions to be reviewed by the Technical Committee.
  • to give inputs for the roadmap prioritization
  • to raise - Producer and Consumer user - requirements toward the Gaia-X functional and operational models to handle
    • interoperability
    • security
    • scalability

Delivery process

journey title Contribution process section Contribution Open a Merge-Request: 5: members, non-members Sign the CLA: 5: members Sign the IPR: 5: non-members section Review Approve/Reject the Merge-Request: 5: maintainers



Source code

An important part of the work is to validate the hypotheses that might have been made during the specifications process, hence the need to prototype and to write demonstrators.

What is a Gaia-X prototype ?

A Gaia-X prototype is a piece of code that answers a specific question.

It can use open-source or closed source software.

The results and conclusions of the prototype must be stored and shareable with the Gaia-X Members on one of the Gaia-X platforms (See the Tools section).

What is a Gaia-X demonstrator ?

A Gaia-X demonstrator is a software implementation that answers a specific user scenario.

It must use open-source or free software.

It must be reproducible by any Gaia-X Member.

The code and documentation must be stored on the Gaia-X Gitlab instance. (See the Tools section)

A running instance of the demo could be hosted under https://<demo>