Features & Benefits

Core services, collaboration capabilities, and strategic benefits of the OpenCloud distributed cloud fabric.

Features & Benefits

Each OpenCloud instance runs a collection of services that allow users to interact with their own deployment and with other OpenCloud participants.
Together, these services form a federated cloud fabric that is both technically powerful and strategically aligned with sovereignty goals.

Core Services

Resource Catalog

The Resource Catalog indexes all resources provided by an OpenCloud instance, including:

  • Data
  • Algorithms
  • Compute Units
  • Storages
  • Processing Workflows

Every resource is described by metadata (see the catalog_metadata definition) and can be:

  • Public – visible to all OpenCloud peers
  • Restricted – visible only to selected partners, projects, entities, or groups

Access to specific resources may require:

  • Credentials
  • Payment
  • Contractual or policy-based agreements

This catalog is the foundation for discoverability, interoperability, and monetization of resources.

Workspace Management

Each OpenCloud user can create workspaces to organize resources of interest.
Within a workspace, users can:

  • Aggregate data, algorithms, and compute/storage units from their own instance and from peers
  • Prepare resources that will be used in processing workflows or permanent services
  • Structure projects by theme, partner, or business objective

Workspaces make complex, multi-partner projects more manageable and traceable.

Workflow Editor

Using resources collected in a workspace, users can build:

  • Distributed processing workflows
  • Permanent services running on top of the OpenCloud fabric

The integrated workflow editor provides a user-friendly interface to define and manage:

  • Processing chains spanning multiple peers
  • Data flows and storage locations
  • Execution policies aligned with sovereignty, cost, or performance objectives

This enables end-to-end distributed workflows without central orchestration dependencies.

Collaborative Areas

OpenCloud supports the creation of Collaborative Areas, where:

  • Workspaces and workflows can be shared with selected partners
  • Rules and constraints can be defined and enforced (automatically or via manual review)

Examples of rules include:

  • Only open-source components allowed in the workflows
  • No personal data allowed, or strict constraints on its use
  • Specific result visibility and sharing policies
  • Legal and compliance limitations tied to jurisdictions or contracts

Collaborative Areas provide a robust framework for governed, multi-party collaboration.

Peer Management

OpenCloud allows you to define and manage relationships with other peers, enabling the creation of:

  • Private communities of trusted partners
  • Thematic or project-based federations

Access rights and trust levels can be configured:

  • At a global peer scope
  • For specific groups or communities within the peer network

This supports fine-grained, community-aware access control across the distributed cloud.

Strategic Benefits

Complete Control Over Data Location

OpenCloud encourages users to host their own data.
When external storage is required, OpenCloud allows you to:

  • Carefully select where data is replicated
  • Choose which peers can host copies
  • Ensure privacy, compliance, and performance through data locality control

Cooperation Framework

OpenCloud provides a structured cooperation framework that covers:

  • Data sharing and common workspaces
  • Usage and access regulations
  • Alignment between technical mechanisms and legal/contractual rules

This framework is particularly suited for cross-organization, regulated, or high-stakes projects.

Data Redundancy with Sovereignty

Like public clouds, OpenCloud supports data redundancy for availability and resilience.
However, it does so with finer-grained control:

  • You decide on which peers and in which jurisdictions your data is replicated
  • Redundancy policies can reflect regulatory or strategic constraints

Hybrid Compatibility with Public Cloud

When workloads require massive storage or computational capabilities beyond what your peer network can provide, you can:

  • Deploy an OpenCloud instance on a public cloud provider
  • Use it as an extension of your federated infrastructure
  • Offload non-sensitive or non-strategic workloads to public cloud capacity

This enables a hybrid architecture where sovereignty-sensitive workloads remain under your control, while others can scale on demand.

Fine-Grained Access Control

OpenCloud offers fine-grained access control mechanisms that allow you to:

  • Define who can access what, from where, and under which conditions
  • Apply policies at the level of resources, workspaces, collaborative areas, and peers
  • Combine technical controls with organizational rules

Lightweight for Datacenter and Edge

The OpenCloud stack is developed in Go, generating:

  • Native binaries
  • Minimal scratch containers

All selected COTS components for OpenCloud services follow the same design philosophy.

As a result, OpenCloud can run:

  • In datacenters, to support large-scale processing workflows
  • On ARM-based single-board computers, to handle concurrent payloads such as:
    • Sensor preprocessing
    • Image recognition
    • Data filtering

Graphical interfaces are implemented in Flutter and rendered as HTML/JS, enabling lightweight deployment with standard web technologies.

Fully Distributed and Resilient

OpenCloud has a fully distributed architecture:

  • No central administrator
  • No central registry or authority
  • No single point of failure

Partners can join or leave the network without disrupting the broader community, making the system inherently resilient and suitable for long-lived collaborations.

Open Source and AGPL v3 Licensed

To foster trust and prevent opaque forks, OpenCloud is released as open-source software under the AGPL v3 license.

This ensures that:

  • The codebase remains transparent and auditable
  • Contributions and modifications remain aligned with the community
  • Closed, private forks cannot undermine the trust and openness of the ecosystem

The source code is publicly available for review, security audits, and community contributions.