BlueSpice 5 is delivered as a container-based application stack. The architecture is modular and can be operated as an all-in-one setup or adapted to use external services such as a custom database, search service or load balancer / reverse proxy. BlueSpice 5 is not installed as a classic manual file-based application; it is primarily provided through container images.
High-level architecture
Users / Browsers
|
v
Load Balancer / Reverse Proxy
|
+-----------------------------+
| |
v v
Frontend Container Frontend Container
Node 1 Node 2 ... n
API / BlueSpice app / API / BlueSpice app /
Resources Resources
| |
+-------------+---------------+
|
v
Shared Backend Services
|
+----------------+----------------+
| | |
Database Storage Search
MariaDB / Shared wiki OpenSearch
MySQL files / data index
MongoDB* directory
|
v
Common Services
Cache, PDF rendering, formula rendering,
diagram editing, Tomcat / Java services,
NodeJS services and other auxiliary services
|
v
Taskrunner Container
Regular tasks / Notifications / Maintenance
* MongoDB is used where features such as collaborative editing require it. The main application database is MySQL or MariaDB; BlueSpice 5 also supports external database services if required.
Load balancer
The Load balancer is the central entry point for users. It accepts HTTPS requests and routes them to one or more frontend containers. In a single-node setup, this can be the proxy container shipped with the BlueSpice stack. In enterprise or high-availability environments, the proxy layer can be replaced by an existing customer load balancer or reverse proxy infrastructure.
The load balancer is responsible for TLS termination, routing, health checks and distribution of traffic across Node 1, Node 2 and additional frontend nodes. Only the frontend containers should receive external web traffic; databases, storage, search and task services remain internal backend services.
Frontend container: API, BlueSpice app and resources
The frontend container is the user-facing application container. It serves the BlueSpice web interface, MediaWiki and BlueSpice APIs, static resources, skins, JavaScript, CSS and user interactions. In the Docker stack this corresponds to the main wiki web service, commonly referred to as wiki-web. The BlueSpice Docker stack defines the main wiki containers as wiki-web and wiki-task.
Frontend containers should be treated as stateless application nodes as much as possible. Persistent data such as wiki content, uploaded files, search indexes and database records must be stored in the shared backend services. This allows additional frontend nodes, shown as Node 2 ... n, to be added behind the load balancer for horizontal scaling.
Taskrunner container: Regular tasks, notifications and maintenance
The taskrunner container handles background work that should not be executed directly in the user request path. This includes regular scheduled jobs, notification processing, maintenance scripts, update tasks, queue processing and other recurring application tasks. In the Docker stack this corresponds to the wiki-task container. During the first startup, the wiki-task container also performs the initial installation and database setup.
Typical responsibilities of the taskrunner include:
- scheduled jobs;
- notification processing;
- maintenance scripts;
- update and housekeeping tasks;
- background processing;
- search indexing jobs where applicable.
In the Docker stack, this role is commonly represented by the wiki-task service.
The taskrunner belongs to the same wiki instance as the frontend container. It must use the same configuration and backend services as that wiki instance.
Database
The database stores the structured application data of the wiki, including pages, revisions, users, permissions, configuration data and extension data. BlueSpice 5 uses MySQL or MariaDB for the main application database. The standard container stack includes database services, but external database services can also be configured.
The database is part of the persistent data context of a specific wiki instance.
Storage
Storage contains persistent file-based data such as uploaded files, generated files, configuration-related data and other wiki data that must survive container restarts or replacement. In a multi-node architecture, storage must be shared between all frontend and taskrunner containers so that every node sees the same files and application state.
The Docker deployment uses a configurable data directory, for example DATADIR=/data/bluespice, to store persistent data outside the containers.
At the moment BlueSpice 5 does not provide a shared resources module or shared file system for uploaded files across independent wiki instances.
Search
Search is provided by OpenSearch. BlueSpice 5 supports OpenSearch 2.x with the ingest-attachments plugin, which enables indexing of wiki content and attached files.
Search is generally handled on a wiki-instance basis. In wiki farm environments, instances can be configured to participate in global search, so that a search in one wiki can also return results from other configured wiki instances.
Common services
Common services are auxiliary services required by the BlueSpice application. Depending on the edition and enabled features, these can include services for caching, rendering, PDF export, formulas, diagrams, Java/Tomcat-based services, NodeJS-based services and other supporting functionality.
Node 2 ... n: Horizontal scaling
Additional nodes can be added by running further frontend containers behind the load balancer. This is the primary horizontal scaling model for BlueSpice web traffic. The operating manual explicitly notes that BlueSpice can run in a distributed environment and that one possible scenario is horizontal scaling of the web frontend service.
In this model, Node 1, Node 2 and all further nodes are equivalent application nodes. They do not store authoritative application data locally. Instead, they rely on the shared database, shared storage, shared search service and shared common services. This makes it possible to scale user-facing traffic while keeping the application data consistent.
Request and processing flow
A typical user request flows through the load balancer to one of the available frontend containers. The frontend container serves the BlueSpice interface, processes API calls and retrieves or writes data through the database, storage and search services. Static resources are delivered by the frontend container, while backend functions such as search indexing, notifications, maintenance and scheduled jobs are handled by the taskrunner.
This separation allows BlueSpice 5 to support both simple deployments and larger distributed environments. The same architectural model can start with a single node and later be extended with additional frontend nodes, external database services, external search services or an existing enterprise load balancer.
