Architecture overview

Below is an overview of the Pydio Cells architecture (click on it to see the detail):

As explained in the previous section, public access APIs are following the “API Gateway” pattern: gRPC services may provide an additional gateway service that translates HTTP REST into gRPC. A dedicated service is acting as a proxy to dispatch incoming queries to these gateways.

The data is exposed via a set of standard protocols:

  • Authentication is following the OpenID Connect Protocol, an identity layer on top of OAuth2, using JSON Web Tokens (JWT)
  • Files can be managed using the Amazon S3 protocol.
  • Activities are published in the Activity Streams 2.0 format (by W3C).
  • Logs are redirected to the stdout in JSON format, to be aggregated in ELK or similar.

It is stored in various ways:

  • Application metadata, specific business data (users & roles, chat, tasks…) are persisted in a database. For the moment, production servers can run with MySQL (or mariaDB equivalent). Tests are done using SQLite.
  • Logs and semi persistent data (like various queues) are persisted in an embedded KVStore (BoltDB).
  • The Files themselves are stored in the underlying datasources (see relevant resources).
  • A small amount of tactical info is directly stored in a few files, typically:
    • Main configuration is stored in a pydio.json file,
    • License for the enterprise edition is stored in a pydio-license file.
Back to top