update docs regarding host mode

README.md

@@ -77,9 +77,6 @@ passworrd | `admin`
 
 ### Network
 
-As the connection of WebRTC relies on delicate network routing we deploy the Janus service in docker network mode `host` instead of `bridge` which puts every service behind a NAT.
-The `host` method has the disadvantage that every port we expose within our container is also exposed on our host which an lead to port clashes as well as security problems so please be sure that the firewall is set up correctly.
-
 As WebRTC only works within a SSL environment we use a nginx reverse proxy to forward the port `8089` to the local port `8088` which is the http version of the Janus server.
 By doing this we can let nginx handle the SSL context and not need to embed this into Janus.
 

docs/deployment.rst

@@ -1,21 +1,11 @@
 Deployment
 ==========
 
-The only supported way to deploy Gencaster is by using Docker.
-This allows for easier development but also introduces some challenges regarding WebRTC communication and CPU realtime priority.
-
 Docker
 ------
 
-As WebRTC relies on a peer-to-peer connection it is necessary to run the streaming container :ref:`caster-sound` in ``host`` mode as otherwise the connection can not be initiated because of a lack of proper IP propagation because otherwise the Docker network acts as a NAT.
-For more information regarding this topic refer to the `Mozilla Documentation <https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Protocols>`_.
-
-.. important::
-
-    ``host`` mode uses ports on the host machine directly rather than forwarding them from the Docker NAT.
-    The result is: **it is only possible to run ONE instance of Gencaster on a server**.
-    Also all necessary ports need to be free on the host.
-
+As the setup of the streaming stack is delicate the only supported way of deployment is via `docker compose` which automates most of the setup procedure.
+Yet it is still necessary to provide some config files which are described here.
 
 ``.secrets.env``
 ^^^^^^^^^^^^^^^^