Skip to content

B2SHARE architecture#

Docker stack#

Containers#

The B2SHARE docker stack has the following containers:

frontend#

Image: Custom built nginx alpine with modzip. Dockerfile in docker/nginx/Dockerfile.

The frontend container is used as a http reverse proxy mapping requests to web-ui and web-api containers.

The frontend container is used to server static assets, such as the built React components, static images and stylesheets. These are mapped across the docker stack via static_data volume.

The frontend container is used to offload file downloads from the web-api container. The files are mounted via uploaded_data volume.

The frontend container does TLS termination.

web-api#

Image: B2SHARE application image. Dockerfile is Dockerfile.

The web-api container is used to serve the B2SHARE http REST api.

web-ui#

Image: B2SHARE application image. Dockerfile is Dockerfile.

The web-ui container is used to serve the B2SHARE UI. It serves the Jinja templates.

The web-ui container is used to serve the OAI-PMH.

worker#

Image: B2SHARE application image. Dockerfile is Dockerfile.

The worker container is used to run background tasks and periodic tasks. The tasks are invoked by configured celery beat schedule and celery-beat container. The worker container picks the tasks from RabbitMQ queue.

celery-beat#

Image: B2SHARE application image. Dockerfile is Dockerfile.

The celery-beat container is used to invoke periodic jobs. The jobs are in the database and configured via B2SHARE admin UI. Celery-beat adds the tasks to a RabbitMQ queue from which the worker container picks those up and executes those.

cache#

Image: redis:7

The cache container is used to cache for example community slugs, vocabulary values and sitemap.

db#

Image: postgres:15

The db container is the database.

mq#

Image: rabbitmq:3-management

The mq container is used as a message queue. Different containers (e.g. web-api, web-ui and celery-beat) adds tasks to the message queue from which the worker picks those up and executes those.

Image: opensearchproject/opensearch:2.17.1

The search container is used as a secondary database in form of search indices. It is responsible for storing record view and file download statistics. All searches either via B2SHARE UI or B2SHARE API are made against the search container.

agent#

Image: vault-agent:1.20.2

Optional!

The agent container is used to fetch secrets from an external Vault. The secrets are read by invenio-config module.

pgadmin#

Image: dpage/pgadmin4:6

Optional!

The pgadmin is used as a web interface for the database.

opensearch-dashboards#

Image: opensearchproject/opensearch-dashboards:2.17.1

Optional!

The opensearch-dashboards container is used as a web interface for interacting with search indices stored in search container. It can be used to visualize the indices.

b2share-dev-tools#

Image: B2SHARE application image. Dockerfile is Dockerfile.

Optional!

The b2share-dev-tools container can be used to run commands against a running B2SHARE instance. This can also be done by running the commands in web-api or web-ui containers.

webpack-watch#

Image: B2SHARE application image. Dockerfile is Dockerfile.

Optional!

The webpack watch container can be used to rebuild the B2SHARE UI in watch mode. Read more here.

Volumes#

postgres_data#

Default mount to: ${B2SHARE_DATADIR}/postgres_data

Volume mount for persistent database data.

rabbitmq_data#

Default mount to: ${B2SHARE_DATADIR}/rabbitmq_data

Volume mount for persistent message queue data.

static_data#

Default mount to: ./ui/static

Volume mount for sharing static UI files across the containers (frontend and web-ui).

uploaded_data#

Default mount to: ${B2SHARE_DATADIR}/b2share_data/uploaded_data

Volume mount for files uploaded to B2SHARE.

archived_data#

Default mount to: ${B2SHARE_DATADIR}/b2share_data/archived_data

Currently used only for mounting log file from containers.

opensearch-data#

Default mount to: ${B2SHARE_DATADIR}/opensearch_data

Volume mount for persistent search index data.

celery_run#

Volume for storing information required by celery beat.

Architecture diagram#

Architecture diagram

Figure 1: B2SHARE architecture

  Last update : 11.09.2026

Last review : 11.09.2026