diff --git a/docs/server/source/simple-deployment-template/deploy-a-machine.md b/docs/server/source/simple-deployment-template/deploy-a-machine.md
new file mode 100644
index 00000000..764229d0
--- /dev/null
+++ b/docs/server/source/simple-deployment-template/deploy-a-machine.md
@@ -0,0 +1,69 @@
+<!---
+Copyright BigchainDB GmbH and BigchainDB contributors
+SPDX-License-Identifier: (Apache-2.0 AND CC-BY-4.0)
+Code is Apache-2.0 and docs are CC-BY-4.0
+--->
+
+# Deploy a Machine for Your BigchainDB Node
+
+The first step is to deploy a machine for your BigchainDB node.
+It might be a virtual machine (VM) or a real machine.
+If you follow this simple deployment template, all your node's
+software will run on that one machine.
+
+We don't make any assumptions about _where_ you run the machine.
+It might be in Azure, AWS, your data center or a Raspberry Pi.
+
+## IP Addresses
+
+The following instructions assume all the nodes
+in the network (including yours) have public IP addresses.
+(A BigchainDB network _can_ be run inside a private network,
+using private IP addresses, but we don't cover that here.)
+
+## Operating System
+
+**Use Ubuntu 18.04 or Ubuntu Server 18.04 as the operating system.**
+
+Similar instructions will work on other versions of Ubuntu,
+and other recent Debian-like Linux distros,
+but you may have to change the names of the packages,
+or install more packages.
+
+## Network Security Group
+
+If your machine is in AWS or Azure, for example, _and_
+you want users to connect to BigchainDB via HTTPS,
+then you should configure its network security group
+to allow all incoming and outgoing traffic for:
+
+* TCP on port 22 (SSH)
+* TCP on port 80 (HTTP)
+* TCP on port 443 (HTTPS)
+* Any protocol on port 26656 (Tendermint P2P)
+
+If you don't care about HTTPS, then forget about port 443,
+and replace port 80 with port 9984 (the default BigchainDB HTTP port).
+
+## Update Your System
+
+SSH into your machine and update all its OS-level packages:
+
+```
+sudo apt update
+sudo apt full-upgrade
+```
+
+## Node Security
+
+If you're going to use your node in production,
+then you should take additional steps to secure it.
+We don't cover that here; there are many books and websites
+about securing Linux machines.
+
+## DNS Setup
+
+* Register a domain name for your BigchainDB node, such as `example.com`
+* Pick a subdomain of that domain for your BigchainDB node, such as `bnode.example.com`
+* Create a DNS "A Record" pointing your chosen subdomain (such as `bnode.example.com`)
+  at your machine's IP address.
diff --git a/docs/server/source/simple-deployment-template/index.rst b/docs/server/source/simple-deployment-template/index.rst
index 9ee713c2..55f277da 100644
--- a/docs/server/source/simple-deployment-template/index.rst
+++ b/docs/server/source/simple-deployment-template/index.rst
@@ -8,14 +8,34 @@
 Simple Deployment Template
 ==========================
 
-This section describes *one* way to deploy a BigchainDB network.
-You can modify it as you see fit.
+This section describes *one* way to deploy a BigchainDB network
+(i.e. a set of connected BigchainDB nodes).
+You can modify this simple deployment template as you see fit.
 It's "simple" in the sense that each BigchainDB node is installed
 and run on a single virtual machine (or real machine).
 We also have a :ref:`kubernetes-deployment-template` (not simple).
 
+**Note 1:** These instructions will also work for a "network" with only one node.
+If you want your network to be able to handle the failure or misbehavior
+of one node, then your network must have at least four nodes.
+Nodes can be added or removed from a network after is it up and running.
+
+**Note 2:** You might not need to set up your own network yet.
+You should start by creating a proof-of-concept app that writes to
+[the BigchainDB Testnet](https://testnet.bigchaindb.com/),
+and if that goes well, then you can look into setting up your own network.
+
+**Note 3:** If you want to set up a node or network
+so that you can contribute to developing and testing the BigchainDB code,
+then see
+[the docs about contributing to BigchainDB](https://docs.bigchaindb.com/projects/contributing/en/latest/index.html).
+
 .. toctree::
    :maxdepth: 1
 
+   deploy-a-machine
+   set-up-nginx
+   set-up-node-software
    network-setup
+   tips
    troubleshooting
diff --git a/docs/server/source/simple-deployment-template/network-setup.md b/docs/server/source/simple-deployment-template/network-setup.md
index c3057895..79bb4385 100644
--- a/docs/server/source/simple-deployment-template/network-setup.md
+++ b/docs/server/source/simple-deployment-template/network-setup.md
@@ -6,132 +6,23 @@ Code is Apache-2.0 and docs are CC-BY-4.0
 
 # How to Set Up a BigchainDB Network
 
-Note 1: These instructions will also work for a "network" with only one node.
+Until now, everything could be done by a node operator, by themselves.
+Now the node operators, also called **Members**, must share some information
+with each other, so they can form a network.
 
-Note 2: You might not need to set up your own network yet. You should start by creating a proof-of-concept app that writes to [the BigchainDB Testnet](https://testnet.bigchaindb.com/), and if that goes well, then you can look into setting up your own network.
+There is one special Member who helps coordinate everyone: the **Coordinator**.
 
-Note 3: If you want to set up a node or network so that you can contribute to developing and testing the BigchainDB code, then see [the docs about contributing to BigchainDB](https://docs.bigchaindb.com/projects/contributing/en/latest/index.html).
+## Member: Share hostname, pub_key.value and node_id
 
-<hr>
+Each BigchainDB node is identified by its:
 
-The process to create a network is both *social* and *technical*: *social* because someone (that we will call **Coordinator**) needs to find at least three other **Members** willing to join the network, and coordinate the effort; *technical* because each member of the network needs to set up a machine running BigchainDB. (Note: a Coordinator is a Member as well.)
+* `hostname`, i.e. the node's DNS subdomain, such as `bnode.example.com`, or its IP address, such as `46.145.17.32`
+* Tendermint `pub_key.value`
+* Tendermint `node_id`
 
-A **BigchainDB Network** (or just *Network*) is a set of **4 or more BigchainDB Nodes** (or *Nodes*). Every Node is independently managed by a Member, and runs an instance of the [BigchainDB Server software][bdb:software]. At the **Genesis** of a Network, there **MUST** be at least **4** Nodes ready to connect. After the Genesis, a Network can dynamically add new Nodes or remove old Nodes.
-
-A Network will stop working if more than one third of the Nodes are down or faulty _in any way_. The bigger a Network, the more failures it can handle. A Network of size 4 can tolerate only 1 failure, so if 3 out of 4 Nodes are online, everything will work as expected. Eventually, the Node that was offline will automatically sync with the others.
-
-## Before We Start
-
-This tutorial assumes you have basic knowledge on how to manage a GNU/Linux machine.
-
-**Please note: The commands on this page work on Ubuntu 18.04. Similar commands will work on other versions of Ubuntu, and other recent Debian-like Linux distros, but you may have to change the names of the packages, or install more packages.**
-
-We don't make any assumptions about **where** you run the Node.
-You can run BigchainDB Server on a Virtual Machine on the cloud, on a machine in your data center, or even on a Raspberry Pi. Just make sure that your Node is reachable by the other Nodes. Here's a **non-exhaustive list of examples**:
-
-- **good**: all Nodes running in the cloud using public IPs.
-- **bad**: some Nodes running in the cloud using public IPs, some Nodes in a private network.
-- **good**: all Nodes running in a private network.
-
-The rule of thumb is: if Nodes can ping each other, then you are good to go.
-
-The next sections are labelled with **Member** or **Coordinator**, depending on who should follow the instructions. Remember, a Coordinator is also a Member.
-
-## Member: Set Up a Node
-
-Every Member in the Network **must** set up its own Node. The process consists of installing three components, BigchainDB Server, Tendermint Core, and MongoDB, and configuring the firewall.
-
-**Important note on security: it's up to the Member to harden their system.**
-
-### Install the Required Software
-
-Make sure your system is up to date.
-
-```
-sudo apt update
-sudo apt full-upgrade
-```
-
-#### Install BigchainDB Server
-
-BigchainDB Server requires **Python 3.6+**, so make sure your system has it. Install the required packages:
-
-```
-# For Ubuntu 18.04:
-sudo apt install -y python3-pip libssl-dev
-# Ubuntu 16.04, and other Linux distros, may require other packages or more packages
-```
-
-Now install the latest version of BigchainDB. You can find the latest version by going to the [BigchainDB project release history page on PyPI][bdb:pypi]. For example, to install version 2.0.0b7, you would do:
-
-```
-# Change 2.0.0b7 to the latest version as explained above:
-sudo pip3 install bigchaindb==2.0.0b7
-```
-
-Check that you installed the correct version of BigchainDB Server using `bigchaindb --version`.
-
-#### Install (and Start) MongoDB
-
-Install a recent version of MongoDB. BigchainDB Server requires version 3.4 or newer.
-
-```
-sudo apt install mongodb
-```
-
-If you install MongoDB using the above command (which installs the `mongodb` package), it also configures MongoDB, starts MongoDB (in the background), and installs a MongoDB startup script (so that MongoDB will be started automatically when the machine is restarted).
-
-Note: The `mongodb` package is _not_ the official MongoDB package from MongoDB the company. If you want to install the official MongoDB package, please see [the MongoDB documentation](https://docs.mongodb.com/manual/installation/). Note that installing the official package _doesn't_ also start MongoDB.
-
-#### Install Tendermint
-
-The version of BigchainDB Server described in these docs only works well with Tendermint 0.22.8 (not a higher version number). Install that:
-
-```
-sudo apt install -y unzip
-wget https://github.com/tendermint/tendermint/releases/download/v0.22.8/tendermint_0.22.8_linux_amd64.zip
-unzip tendermint_0.22.8_linux_amd64.zip
-rm tendermint_0.22.8_linux_amd64.zip
-sudo mv tendermint /usr/local/bin
-```
-
-### Set Up the Firewall
-
-Make sure to accept inbound connections on ports `9984`, `9985`, and `26656`. You might also want to add port `22` so that you can continue to access the machine via SSH.
-
-```
-sudo ufw allow 22/tcp
-sudo ufw allow 9984/tcp
-sudo ufw allow 9985/tcp
-sudo ufw allow 26656/tcp
-sudo ufw enable
-```
-
-Some cloud providers, like Microsoft Azure, require you to change "security groups" (virtual firewalls) using their portal or other APIs (such as their CLI).
-
-## Member: Configure BigchainDB Server
-
-To configure BigchainDB Server, run:
-
-```
-bigchaindb configure
-```
-
-The first question is ``API Server bind? (default `localhost:9984`)``. To expose the API to the public, bind the API Server to `0.0.0.0:9984`. Unless you have specific needs, you can keep the default value for all other questions.
-
-## Member: Generate the Private Key and Node id
-
-A Node is identified by the triplet `<hostname, node_id, public_key>`.
-
-As a Member, it's your duty to create and store securely your private key, and share your `hostname`, `node_id`, and `public_key` with the other members of the network.
-
-To generate all of that, run:
-
-```
-tendermint init
-```
-
-The `public_key` is stored in the file `.tendermint/config/priv_validator.json`, and it should look like:
+The Tendermint `pub_key.value` is stored
+in the file `$HOME/.tendermint/config/priv_validator.json`.
+That file should look like:
 
 ```json
 {
@@ -150,7 +41,7 @@ The `public_key` is stored in the file `.tendermint/config/priv_validator.json`,
 }
 ```
 
-To extract your `node_id`, run the command:
+To get your Tendermint `node_id`, run the command:
 
 ```
 tendermint show_node_id
@@ -158,15 +49,13 @@ tendermint show_node_id
 
 An example `node_id` is `9b989cd5ac65fec52652a457aed6f5fd200edc22`.
 
-An example hostname is `charlie5.cloudservers.company.com`. You can also use a public IP addres, like `46.145.17.32`, instead of a hostname, but make sure that IP address won't change.
+**Share your `hostname`, `pub_key.value` and `node_id` with all other Members.**
 
-Share the `node_id`, `pub_key.value` and hostname of your Node with all other Members.
+## Coordinator: Create & Share the genesis.json File
 
-**Important note on security: each Member should take extra steps to verify the public keys they receive from the other Members have not been tampered with, e.g. a key signing party would be one way.**
-
-## Coordinator: Initialize the Network
-
-At this point the Coordinator should have received the data from all the Members, and should combine them in the `.tendermint/config/genesis.json` file:
+At this point the Coordinator should have received the data
+from all the Members, and should combine them in the file
+`$HOME/.tendermint/config/genesis.json`:
 
 ```json
 {
@@ -225,9 +114,12 @@ At this point the Coordinator should have received the data from all the Members
 }
 ```
 
-**Note:** `consensus_params` in the `genesis.json` are default values for Tendermint consensus.
+**Note:** The above `consensus_params` in the `genesis.json`
+are default values.
 
-The new `genesis.json` file contains the data that describes the Network. The key `name` is the Member's moniker; it can be any valid string, but put something human-readable like `"Alice's Node Shop"`.
+The new `genesis.json` file contains the data that describes the Network.
+The key `name` is the Member's moniker; it can be any valid string,
+but put something human-readable like `"Alice's Node Shop"`.
 
 At this point, the Coordinator must share the new `genesis.json` file with all Members.
 
@@ -235,11 +127,13 @@ At this point, the Coordinator must share the new `genesis.json` file with all M
 
 At this point the Member should have received the `genesis.json` file.
 
-**Important note on security: each Member should verify that the `genesis.json` file contains the correct public keys.**
+The Member must copy the `genesis.json` file
+into their local `$HOME/.tendermint/config` directory.
+Every Member now shares the same `chain_id` and `genesis_time` (used to identify the Network),
+and the same list of `validators`.
 
-The Member must copy the `genesis.json` file in the local `.tendermint/config` directory. Every Member now shares the same `chain_id`, `genesis_time`, used to identify the Network, and the same list of `validators`.
-
-The Member must edit the `.tendermint/config/config.toml` file and make the following changes:
+Each Member must edit their `$HOME/.tendermint/config/config.toml` file
+and make the following changes:
 
 ```
 moniker = "Name of our node"
@@ -256,6 +150,9 @@ recv_rate = 102400000
 recheck = false
 ```
 
+Note: The list of `persistent_peers` doesn't have to include all nodes
+in the network.
+
 ## Member: Start MongoDB
 
 If you installed MongoDB using `sudo apt install mongodb`, then MongoDB should already be running in the background. You can check using `systemctl status mongodb`.
@@ -300,65 +197,7 @@ If you want to start and manage the BigchainDB and Tendermint processes yourself
 
 ## How Others Can Access Your Node
 
-If you followed the above instructions, then your node should be publicly-accessible with BigchainDB Root URL `http://hostname:9984` (where hostname is something like `bdb7.canada.vmsareus.net` or `17.122.200.76`). That is, anyone can interact with your node using the [BigchainDB HTTP API](http-client-server-api.html) exposed at that address. The most common way to do that is to use one of the [BigchainDB Drivers](./drivers-clients/index.html).
-
-## Refreshing Your Node
-
-If you want to refresh your node back to a fresh empty state, then your best bet is to terminate it and deploy a new virtual machine, but if that's not an option, then you can:
-
-- drop the `bigchain` database in MongoDB using `bigchaindb drop` (but that only works if MongoDB is running)
-- reset Tendermint using `tendermint unsafe_reset_all`
-- delete the directory `$HOME/.tendermint`
-
-## Shutting down BigchainDB
-
-If you want to stop/kill BigchainDB, you can do so by sending `SIGINT`, `SIGQUIT` or `SIGTERM` to the running BigchainDB
-process(es). Depending on how you started BigchainDB i.e. foreground or background. e.g. you started BigchainDB in the background as mentioned above in the guide:
-
-```bash
-$ nohup bigchaindb start 2>&1 > bigchaindb.log &
-
-$ # Check the PID of the main BigchainDB process
-$ ps -ef | grep bigchaindb
-<user>    *<pid> <ppid>   <C> <STIME> <tty>        <time> bigchaindb
-<user>     <pid> <ppid>*  <C> <STIME> <tty>        <time> gunicorn: master [bigchaindb_gunicorn]
-<user>     <pid> <ppid>*  <C> <STIME> <tty>        <time> bigchaindb_ws
-<user>     <pid> <ppid>*  <C> <STIME> <tty>        <time> bigchaindb_ws_to_tendermint
-<user>     <pid> <ppid>*  <C> <STIME> <tty>        <time> bigchaindb_exchange
-<user>     <pid> <ppid>   <C> <STIME> <tty>        <time> gunicorn: worker [bigchaindb_gunicorn]
-<user>     <pid> <ppid>   <C> <STIME> <tty>        <time> gunicorn: worker [bigchaindb_gunicorn]
-<user>     <pid> <ppid>   <C> <STIME> <tty>        <time> gunicorn: worker [bigchaindb_gunicorn]
-<user>     <pid> <ppid>   <C> <STIME> <tty>        <time> gunicorn: worker [bigchaindb_gunicorn]
-<user>     <pid> <ppid>   <C> <STIME> <tty>        <time> gunicorn: worker [bigchaindb_gunicorn]
-...
-
-$ # Send any of the above mentioned signals to the parent/root process(marked with `*` for clarity)
-# Sending SIGINT
-$ kill -2 <bigchaindb_parent_pid>
-
-$ # OR
-
-# Sending SIGTERM
-$ kill -15 <bigchaindb_parent_pid>
-
-$ # OR
-
-# Sending SIGQUIT
-$ kill -3 <bigchaindb_parent_pid>
-
-# If you want to kill all the processes by name yourself
-$ pgrep bigchaindb | xargs kill -9
-```
-
-If you started BigchainDB in the foreground, a `Ctrl + C` or `Ctrl + Z` would shut down BigchainDB.
-
-## Member: Dynamically Add or Remove Validators
-
-One member can make a proposal to call an election to add a validator, remove a validator, or change the voting power of a validator. They then share the election/proposal ID with all the other members. Once more than 2/3 of the voting power votes yes, the proposed change comes into effect. The commands to create a new election/proposal, to approve an election/proposal, and to get the current status of an election/proposal can be found in the documentation about the [bigchaindb election](../server-reference/bigchaindb-cli.html#bigchaindb-election) subcommands.
-
-## Logging and Log Rotation
-
-See the page in the Appendices about [logging and log rotation](../appendices/log-rotation.html).
+If you followed the above instructions, then your node should be publicly-accessible with BigchainDB Root URL `https://hostname` or `http://hostname:9984`. That is, anyone can interact with your node using the [BigchainDB HTTP API](http-client-server-api.html) exposed at that address. The most common way to do that is to use one of the [BigchainDB Drivers](./drivers-clients/index.html).
 
 [bdb:software]: https://github.com/bigchaindb/bigchaindb/
 [bdb:pypi]: https://pypi.org/project/BigchainDB/#history
diff --git a/docs/server/source/simple-deployment-template/set-up-nginx.md b/docs/server/source/simple-deployment-template/set-up-nginx.md
new file mode 100644
index 00000000..77f32834
--- /dev/null
+++ b/docs/server/source/simple-deployment-template/set-up-nginx.md
@@ -0,0 +1,42 @@
+<!---
+Copyright BigchainDB GmbH and BigchainDB contributors
+SPDX-License-Identifier: (Apache-2.0 AND CC-BY-4.0)
+Code is Apache-2.0 and docs are CC-BY-4.0
+--->
+
+# Set Up NGINX
+
+If you don't want HTTPS
+(for communications between the external world and your node),
+then you can skip all the NGINX steps on this page.
+
+Note: This simple deployment template uses NGINX for more than just HTTPS.
+For example, it also does basic rate limiting.
+
+## Install NGINX
+
+SSH into your machine and install NGINX:
+
+```
+sudo apt update
+sudo apt install nginx
+```
+
+## Configure & Reload NGINX
+
+Get an SSL certificate for your node's subdomain (such as `bnode.example.com`).
+
+* Copy the SSL private key into `/etc/nginx/ssl/cert.key`
+* Create a "PEM file" (text file) by concatenating your SSL certificate with all intermediate certificates (_in that order, with the intermediate certs last_).
+* Copy that PEM file into `/etc/nginx/ssl/cert.pem`
+* In the
+  [bigchaindb/bigchaindb repository on GitHub](https://github.com/bigchaindb/bigchaindb),
+  find the file `nginx/nginx.conf` and copy its contents to
+  `/etc/nginx/nginx.conf` on your machine (i.e. replace the existing file there).
+* Edit that file (`/etc/nginx/nginx.conf`): replace the two instances of
+  the string `example.testnet2.com`
+  with your chosen subdomain (such as `bnode.example.com`).
+* Reload NGINX by doing:
+  ```
+  sudo service nginx reload
+  ```
diff --git a/docs/server/source/simple-deployment-template/set-up-node-software.md b/docs/server/source/simple-deployment-template/set-up-node-software.md
new file mode 100644
index 00000000..1ddf12cd
--- /dev/null
+++ b/docs/server/source/simple-deployment-template/set-up-node-software.md
@@ -0,0 +1,104 @@
+<!---
+Copyright BigchainDB GmbH and BigchainDB contributors
+SPDX-License-Identifier: (Apache-2.0 AND CC-BY-4.0)
+Code is Apache-2.0 and docs are CC-BY-4.0
+--->
+
+# Set Up BigchainDB, MongoDB and Tendermint
+
+We now install and configure software that must run
+in every BigchainDB node: BigchainDB Server,
+MongoDB and Tendermint.
+
+## Install BigchainDB Server
+
+BigchainDB Server requires **Python 3.6+**, so make sure your system has it.
+Install the required OS-level packages:
+
+```
+# For Ubuntu 18.04:
+sudo apt install -y python3-pip libssl-dev
+# Ubuntu 16.04, and other Linux distros, may require other packages or more packages
+```
+
+Now install the latest version of BigchainDB Server.
+You can find the latest version by going
+to the [BigchainDB project release history page on PyPI][bdb:pypi].
+For example, to install version 2.0.0b7, you would do:
+
+```
+# Change 2.0.0b7 to the latest version as explained above:
+sudo pip3 install bigchaindb==2.0.0b7
+```
+
+Check that you installed the correct version of BigchainDB Server using `bigchaindb --version`.
+
+## Configure BigchainDB Server
+
+To configure BigchainDB Server, run:
+
+```
+bigchaindb configure
+```
+
+The first question is ``API Server bind? (default `localhost:9984`)``.
+
+* If you're using NGINX (e.g. if you want HTTPS),
+  then accept the default value (`localhost:9984`).
+* If you're not using NGINX, then enter the value `0.0.0.0:9984`
+
+You can accept the default value for all other BigchainDB config settings.
+
+If you're using NGINX, then you should edit your BigchainDB config file
+(in `$HOME/.bigchaindb` by default) and set the following values
+under `"wsserver"`:
+
+```
+"advertised_scheme": "wss",
+"advertised_host": "bnode.example.com",
+"advertised_port": 443
+```
+
+where `bnode.example.com` should be replaced by your node's actual subdomain.
+
+## Install (and Start) MongoDB
+
+Install a recent version of MongoDB.
+BigchainDB Server requires version 3.4 or newer.
+
+```
+sudo apt install mongodb
+```
+
+If you install MongoDB using the above command (which installs the `mongodb` package),
+it also configures MongoDB, starts MongoDB (in the background),
+and installs a MongoDB startup script
+(so that MongoDB will be started automatically when the machine is restarted).
+
+Note: The `mongodb` package is _not_ the official MongoDB package
+from MongoDB the company. If you want to install the official MongoDB package,
+please see
+[the MongoDB documentation](https://docs.mongodb.com/manual/installation/).
+Note that installing the official package _doesn't_ also start MongoDB.
+
+## Install Tendermint
+
+The version of BigchainDB Server described in these docs only works well
+with Tendermint 0.22.8 (not a higher version number). Install that:
+
+```
+sudo apt install -y unzip
+wget https://github.com/tendermint/tendermint/releases/download/v0.22.8/tendermint_0.22.8_linux_amd64.zip
+unzip tendermint_0.22.8_linux_amd64.zip
+rm tendermint_0.22.8_linux_amd64.zip
+sudo mv tendermint /usr/local/bin
+```
+
+## Start Configuring Tendermint
+
+You won't be able to finish configuring Tendermint until you have some information
+from the other nodes in the network, but you can start by doing:
+
+```
+tendermint init
+```
diff --git a/docs/server/source/simple-deployment-template/tips.md b/docs/server/source/simple-deployment-template/tips.md
new file mode 100644
index 00000000..710dbd78
--- /dev/null
+++ b/docs/server/source/simple-deployment-template/tips.md
@@ -0,0 +1,59 @@
+# Tips
+
+## Refreshing Your Node
+
+If you want to refresh your node back to a fresh empty state, then your best bet is to terminate it and deploy a new machine, but if that's not an option, then you can:
+
+* drop the `bigchain` database in MongoDB using `bigchaindb drop` (but that only works if MongoDB is running)
+* reset Tendermint using `tendermint unsafe_reset_all`
+* delete the directory `$HOME/.tendermint`
+
+## Shutting Down BigchainDB
+
+If you want to stop/kill BigchainDB, you can do so by sending `SIGINT`, `SIGQUIT` or `SIGTERM` to the running BigchainDB
+process(es). Depending on how you started BigchainDB i.e. foreground or background. e.g. you started BigchainDB in the background as mentioned above in the guide:
+
+```bash
+$ nohup bigchaindb start 2>&1 > bigchaindb.log &
+
+$ # Check the PID of the main BigchainDB process
+$ ps -ef | grep bigchaindb
+<user>    *<pid> <ppid>   <C> <STIME> <tty>        <time> bigchaindb
+<user>     <pid> <ppid>*  <C> <STIME> <tty>        <time> gunicorn: master [bigchaindb_gunicorn]
+<user>     <pid> <ppid>*  <C> <STIME> <tty>        <time> bigchaindb_ws
+<user>     <pid> <ppid>*  <C> <STIME> <tty>        <time> bigchaindb_ws_to_tendermint
+<user>     <pid> <ppid>*  <C> <STIME> <tty>        <time> bigchaindb_exchange
+<user>     <pid> <ppid>   <C> <STIME> <tty>        <time> gunicorn: worker [bigchaindb_gunicorn]
+<user>     <pid> <ppid>   <C> <STIME> <tty>        <time> gunicorn: worker [bigchaindb_gunicorn]
+<user>     <pid> <ppid>   <C> <STIME> <tty>        <time> gunicorn: worker [bigchaindb_gunicorn]
+<user>     <pid> <ppid>   <C> <STIME> <tty>        <time> gunicorn: worker [bigchaindb_gunicorn]
+<user>     <pid> <ppid>   <C> <STIME> <tty>        <time> gunicorn: worker [bigchaindb_gunicorn]
+...
+
+$ # Send any of the above mentioned signals to the parent/root process(marked with `*` for clarity)
+# Sending SIGINT
+$ kill -2 <bigchaindb_parent_pid>
+
+$ # OR
+
+# Sending SIGTERM
+$ kill -15 <bigchaindb_parent_pid>
+
+$ # OR
+
+# Sending SIGQUIT
+$ kill -3 <bigchaindb_parent_pid>
+
+# If you want to kill all the processes by name yourself
+$ pgrep bigchaindb | xargs kill -9
+```
+
+If you started BigchainDB in the foreground, a `Ctrl + C` or `Ctrl + Z` would shut down BigchainDB.
+
+## Member: Dynamically Add or Remove Validators
+
+One member can make a proposal to call an election to add a validator, remove a validator, or change the voting power of a validator. They then share the election/proposal ID with all the other members. Once more than 2/3 of the voting power votes yes, the proposed change comes into effect. The commands to create a new election/proposal, to approve an election/proposal, and to get the current status of an election/proposal can be found in the documentation about the [bigchaindb election](../server-reference/bigchaindb-cli.html#bigchaindb-election) subcommands.
+
+## Logging and Log Rotation
+
+See the page in the Appendices about [logging and log rotation](../appendices/log-rotation.html).
\ No newline at end of file
diff --git a/nginx/nginx.conf b/nginx/nginx.conf
new file mode 100644
index 00000000..a22abc10
--- /dev/null
+++ b/nginx/nginx.conf
@@ -0,0 +1,125 @@
+# Copyright BigchainDB GmbH and BigchainDB contributors
+# SPDX-License-Identifier: (Apache-2.0 AND CC-BY-4.0)
+# Code is Apache-2.0 and docs are CC-BY-4.0
+
+# NOTE: You must replace example.testnet2.com
+# with your node's actual DNS name in TWO PLACES below.
+
+# Frontend API server
+worker_processes 4;
+user nobody nogroup;
+error_log /var/log/nginx/error.log;
+
+events {
+  # Each worker handles up to 512 connections. Increase this for heavy
+  # workloads.
+  worker_connections 64;
+  accept_mutex on;
+  use epoll;
+}
+
+http {
+  access_log /var/log/nginx/access.log combined buffer=16k flush=5s;
+
+  # Allow 10 req/sec from the same IP address, and store the counters in a
+  # `zone` or shared memory location tagged as 'one'.
+  limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;
+
+  # Enable logging when requests are being throttled.
+  limit_req_log_level notice;
+
+  # HTTP status code that is returned to the client; 429 is for TooManyRequests,
+  # ref. RFC 6585
+  limit_req_status 429;
+
+  # Limit requests from the same client, allow `burst` to 20 r/s,
+  # `nodelay` or drop connection immediately in case it exceeds this
+  # threshold.
+  limit_req zone=one burst=20 nodelay;
+
+  # `slowloris` attack mitigation settings.
+  client_body_timeout 10s;
+  client_header_timeout 10s;
+
+  # Do not expose NGINX data/version number in error response and header
+  server_tokens off;
+
+  # To prevent cross-site scripting
+  add_header X-XSS-Protection "1; mode=block";
+
+  keepalive_timeout 60s;
+
+  # Frontend server for the external clients; acts as HTTPS termination point.
+  server {
+    listen 443 ssl;
+    server_name "example.testnet2.com";
+
+    ssl_certificate /etc/nginx/ssl/cert.pem;
+    ssl_certificate_key /etc/nginx/ssl/cert.key;
+    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
+    ssl_ciphers HIGH:!aNULL:!MD5;
+
+    underscores_in_headers on;
+
+    # Forward websockets directly to backend BDB.
+    location /api/v1/streams/valid_transactions {
+      proxy_set_header X-Real-IP $remote_addr;
+      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+
+      proxy_pass http://localhost:9985;
+      proxy_read_timeout 600s;
+      proxy_http_version 1.1;
+      proxy_set_header Upgrade $http_upgrade;
+      proxy_set_header Connection "upgrade";
+    }
+
+    # Forward other URL paths as per business logic/use case to BDB
+    location / {
+      proxy_ignore_client_abort on;
+      proxy_set_header X-Real-IP  $remote_addr;
+      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+
+      # max client request body size: average transaction size.
+      client_max_body_size 15k;
+
+      if ($request_method = 'OPTIONS') {
+          add_header 'Access-Control-Allow-Origin' '*';
+          add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
+          add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent';
+          add_header 'Access-Control-Max-Age' 43200;
+          add_header 'Content-Type' 'text/plain charset=UTF-8';
+          add_header 'Content-Length' 0;
+          return 204;
+      }
+
+      proxy_pass http://localhost:9984;
+
+      # Only return this response if request_method is neither POST|GET|OPTIONS
+      if ($request_method !~ ^(GET|OPTIONS|POST)$) {
+          return 444;
+      }
+    }
+  }
+
+  # Frontend server for the load balancer to respond to health checks.
+  server {
+    listen 9000;
+
+    location = /health {
+      return 200;
+    }
+  }
+
+  # Frontend server for the external clients; returns a pretty error message
+  # when an HTTP request is sent instead of HTTPS.
+  server {
+      listen 80;
+      server_name "example.testnet2.com";
+
+      location / {
+          add_header Upgrade "TLS/1.2, HTTP/1.1" always;
+          default_type text/plain;
+          return 426 'Consider using the HTTPS protocol next time!';
+      }
+  }
+}