diff --git a/init/README.md b/init/README.md
index 9410a724..a4c0a7a9 100644
--- a/init/README.md
+++ b/init/README.md
@@ -1,19 +1,19 @@
-# How to run `cc-backend` as a systemd service.
+# How to run `cc-backend` as a systemd service
 
 The files in this directory assume that you install ClusterCockpit to
 `/opt/monitoring/cc-backend`.
 Of course you can choose any other location, but make sure you replace all paths
 starting with `/opt/monitoring/cc-backend` in the `clustercockpit.service` file!
 
-The `config.json` may contain the optional fields *user* and *group*. If
+The `config.json` may contain the optional fields _user_ and _group_. If
 specified, the application will call
 [setuid](https://man7.org/linux/man-pages/man2/setuid.2.html) and
 [setgid](https://man7.org/linux/man-pages/man2/setgid.2.html) after reading the
 config file and binding to a TCP port (so it can take a privileged port), but
 before it starts accepting any connections. This is good for security, but also
-means that the `var/` directory must be readable and writeable by this user.
-The `config.json` file may contain secrets and should not be readable by this
-user. If this file is changed, the server must be restarted.
+means that the `var/` directory must be readable and writeable by this user. The
+`config.json` file may contain secrets. If this file is changed, the server must
+be restarted.
 
 ```sh
 # 1. Clone this repository somewhere in your home
@@ -55,8 +55,9 @@ It is recommended to install all ClusterCockpit components in a common directory
 In the following we use `/opt/monitoring`.
 
 Two systemd services run on the central monitoring server:
-* clustercockpit : binary cc-backend in `/opt/monitoring/cc-backend`.
-* cc-metric-store : Binary cc-metric-store in `/opt/monitoring/cc-metric-store`.
+
+- clustercockpit : binary cc-backend in `/opt/monitoring/cc-backend`.
+- cc-metric-store : Binary cc-metric-store in `/opt/monitoring/cc-metric-store`.
 
 ClusterCockpit is deployed as a single binary that embeds all static assets.
 We recommend keeping all `cc-backend` binary versions in a folder `archive` and
@@ -66,12 +67,13 @@ This allows for easy roll-back in case something doesn't work.
 ## Workflow to deploy new version
 
 This example assumes the DB and job archive versions did not change.
-* Stop systemd service: `$ sudo systemctl stop clustercockpit.service`
-* Backup the sqlite DB file and Job archive directory tree!
-* Copy `cc-backend` binary to `/opt/monitoring/cc-backend/archive` (Tip: Use a
-date tag like `YYYYMMDD-cc-backend`)
-* Link from cc-backend root to current version
-* Start systemd service: `$ sudo systemctl start clustercockpit.service`
-* Check if everything is ok: `$ sudo systemctl status clustercockpit.service`
-* Check log for issues: `$ sudo journalctl -u clustercockpit.service`
-* Check the ClusterCockpit web frontend and your Slurm adapters if anything is broken!
+
+- Stop systemd service: `$ sudo systemctl stop clustercockpit.service`
+- Backup the sqlite DB file and Job archive directory tree!
+- Copy `cc-backend` binary to `/opt/monitoring/cc-backend/archive` (Tip: Use a
+  date tag like `YYYYMMDD-cc-backend`)
+- Link from cc-backend root to current version
+- Start systemd service: `$ sudo systemctl start clustercockpit.service`
+- Check if everything is ok: `$ sudo systemctl status clustercockpit.service`
+- Check log for issues: `$ sudo journalctl -u clustercockpit.service`
+- Check the ClusterCockpit web frontend and your Slurm adapters if anything is broken!