seatable · simonhammes · Aug 28, 2025 · Aug 28, 2025 · Aug 28, 2025 · Aug 28, 2025
diff --git a/docs/installation/cluster/dtable-db-standalone.md b/docs/installation/cluster/dtable-db-standalone.md
@@ -123,7 +123,7 @@ After the first start of `dtable-db` you need to make the following changes to n
 
 ??? success "Add S3 configuration"
 
-    Add the S3 configuration to `conf/dtable-storage-server.conf - analog to your first node. 
+    Add the S3 configuration to `conf/dtable-storage-server.conf` - analog to your first node.
 
 ??? success "Two additional configuration changes"
 
@@ -166,7 +166,6 @@ These are the changes, you have to do.
     ```
     environment:
       - ENABLE_DTABLE_DB=false
-      - SEATABLE_START_MODE=first
     extra_hosts:
       - "dtable-web:10.0.0.2"
       - "dtable-db:10.0.0.3"

diff --git a/docs/installation/cluster/dtable-events-background-node.md b/docs/installation/cluster/dtable-events-background-node.md
@@ -32,8 +32,11 @@ SeaTable allows you to **split dtable-events**, moving background tasks to a ded
 1. **Prepare a new node** with Docker installed.
 
 2. **Copy the following files** from your first node to the new node:
-   - `/opt/seatable-compose/.env`
-   - `/opt/seatable-compose/seatable-license.txt`
+      - `/opt/seatable-compose/.env`
+      - `/opt/seatable-compose/seatable-license.txt`
+      - `/opt/seatable-server/seatable/conf/dtable_web_settings.py`
+
+        This is mandatory since **dtable-events** reads some configuration settings from `dtable_web_settings.py`.
 
 3. **Edit the `.env` file** on the new node and set the `COMPOSE_FILE` variable to reference only a single YAML file:
 

diff --git a/docs/installation/cluster/introduction.md b/docs/installation/cluster/introduction.md
@@ -17,12 +17,13 @@ SeaTable can be operated both as a **single-node installation** and in **cluster
 
 In the following instructions for deploying a SeaTable Cluster, I will use the node names and roles listed below as a naming convention. Please adapt these to fit your specific environment.
 
-| Node | Main service / Name | Private IP address |
-| --- | --- | --- |
-| node1 | dtable-web | 10.0.0.2 |
-| node2 | dtable-db | 10.0.0.3 |
-| node3 | dtable-server | 10.0.0.4 |
-| node4 | dtable-server-2 | 10.0.0.5 |
+| Node  | Main service / Name | Private IP address |
+| ----- | ------------------- | ------------------ |
+| node1 | dtable-web          | 10.0.0.2           |
+| node2 | dtable-db           | 10.0.0.3           |
+| node3 | dtable-server       | 10.0.0.4           |
+| node4 | dtable-server-2     | 10.0.0.5           |
+| node5 | dtable-events       | 10.0.0.6           |
 
 ## When is a single-node installation suitable?
 
@@ -60,7 +61,7 @@ Once the single-node setup reaches its performance limits, it is advisable to sw
 
 - All nodes use the same Docker image, but individual components are selectively enabled or disabled.
 - The setup usually starts as a single-node installation. Gradually, individual components are moved to separate nodes.
-- In the maximum expansion stage, each service runs on its own node; multiple `dtable-servers` and multiple `dtable-web` can run in parallel.
+- In the maximum expansion stage, each service runs on its own node; multiple `dtable-servers` and multiple `dtable-web` can run in parallel. Please note that the latter requires _sticky sessions_.
 
 ![SeaTable Cluster Overview](../../assets/images/seatable-cluster-overview.png)
 

diff --git a/docs/installation/cluster/requirements.md b/docs/installation/cluster/requirements.md
@@ -11,7 +11,8 @@ The requirements for running a SeaTable cluster build upon those for a single-no
 - One node (running dtable-web) must be publically available via **port 80 and 443**.
 - **S3-compatible object storage** is required for storing files and attachments. (Alternative storage technologies may be possible but are not covered in detail here.)
 - **Centralized MariaDB and Redis services**: These must be accessible to all nodes in the private network. You can either use managed services or operate your own MariaDB and Redis instances.
-- If you plan to use the **Office Editor** or the **Python Pipeline**, these services must also be provided as separate services within the private network.
+- If you plan to use the **Office Editor**, the service should be deployed within the private network.
+- You can deploy the **Python Pipeline** on the [same node as **dtable-web**](../components/python-pipeline.md) or on a [separate node](../advanced/python-pipeline-dedicated-server.md).
 
 !!! warning "Network communication is often the main challenge"  
 

diff --git a/docs/installation/components/python-pipeline.md b/docs/installation/components/python-pipeline.md
@@ -17,6 +17,11 @@ Find additional Python functions and code examples in the [SeaTable Developer Ma
 
 This how-to explains the deployment of the Python Pipeline next to your SeaTable Server instance.
 
+!!! warning "Security Considerations"
+
+    If you allow untrusted users or users with limited trust to execute Python scripts within SeaTable, you should deploy the Python Pipeline on a separate node without private network access to your SeaTable server instance.
+    Please follow the [documentation](../advanced/python-pipeline-dedicated-server.md) on how to achieve this.
+
 #### Amend the .env file
 
 To install the Python Pipeline, append `python-pipeline.yml` to the `COMPOSE_FILE` variable within your `.env` file. This instructs Docker to download the required images for the Python Pipeline.