diff --git a/docs/swarm/master/README.md b/docs/swarm/master/README.md
index c09f1dd3..2a2a021a 100644
--- a/docs/swarm/master/README.md
+++ b/docs/swarm/master/README.md
@@ -56,12 +56,12 @@ core@coreos-01 ~ $ sudo umount /mnt/local/
 ```
 
 
-### Networking mode
+## Networking mode
 On this example, we are using:
 - the mesh routing mode (default mode). With this mode, each service is given a virtual IP adress and docker manages the routing between this virtual IP and the container(s) providing this service. 
 - the default ingress mode.
 
-## Allow authentification with the mesh routing
+### Allow authentification with the mesh routing
 In order to allow every (front & webmail) container to access the other services, we will use the variable POD_ADDRESS_RANGE.
 
 Let's create the mailu_default network:
@@ -73,7 +73,7 @@ core@coreos-01 ~ $ docker network inspect mailu_default | grep Subnet
 In the docker-compose.yml file, we will then use POD_ADDRESS_RANGE = 10.0.1.0/24 
 In fact, imap & smtp logs doesn't show the IPs from the front(s) container(s), but the IP of  "mailu_default-endpoint". So it is sufficient to set POD_ADDRESS_RANGE to this specific ip (which can be found by inspecting mailu_default network). The issue is that this endpoint is created while the stack is created, I did'nt figure a way to determine this IP before the stack creation...
 
-## Limitation with the ingress mode
+### Limitation with the ingress mode
 With the default ingress mode, the front(s) container(s) will see origin IP(s) all being 10.255.0.x (which is the ingress-endpoint, can be found by inspecting the ingress network)
 
 This issue is known and discussed here:
@@ -84,22 +84,22 @@ A workaround (using network host mode and global deployment) is discussed here:
 
 https://github.com/moby/moby/issues/25526#issuecomment-336363408 
 
-## Don't create an open relay !
+### Don't create an open relay !
 As a side effect of this ingress mode "feature", make sure that the ingress subnet is not in your RELAYHOST, otherwise you would create an smtp open relay :-(
 
 
-### Scalability
+## Scalability
 - smtp and imap are scalable
 - front and webmail are scalable (pending POD_ADDRESS_RANGE is used), although the let's encrypt magic might not like it (race condidtion ? or risk to be banned by let's encrypt server if too many front containers attemps to renew the certs at the same time) 
 - redis, antispam, antivirus, fetchmail, admin, webdav have not been tested (hence replicas=1 in the following docker-compose.yml file)
 
-### Variable substitution and docker-compose.yml
+## Variable substitution and docker-compose.yml
 The docker stack deploy command doesn't support variable substitution in the .yml file itself (but we still can use .env file to pass variables to the services). As a consequence we need to adjust the docker-compose file in order to :
 - remove all variables : $VERSION , $BIND_ADDRESS4 , $BIND_ADDRESS6 , $ANTIVIRUS , $WEBMAIL , etc
 - change the way we define the volumes (nfs share in our case)
 - add a deploy section for every service
 
-### Docker compose 
+## Docker compose 
 An example of docker-compose-stack.yml file is available here:
 
 ```yaml
@@ -340,7 +340,7 @@ volumes:
       device: ":/mnt/Pool1/pv/mailu/redis"
 ```
 
-### Deploy Mailu on the docker swarm
+## Deploy Mailu on the docker swarm
 Run the following command:
 ```bash
 docker stack deploy -c docker-compose-stack.yml mailu
@@ -359,7 +359,7 @@ ID                  NAME                IMAGE                 NODE
 tbu8ppgsdffj        mailu_fetchmail.1   mailu/fetchmail:1.5   coreos-01           Running             Running 11 days ago
 ```
 
-### Remove the stack
+## Remove the stack
 Run the follwoing command:
 ```bash
 core@coreos-01 ~ $ docker stack rm mailu