diff --git a/docs/tutorial/bridge.md b/docs/tutorial/bridge.md
deleted file mode 100644
index 89304ec33..000000000
--- a/docs/tutorial/bridge.md
+++ /dev/null
@@ -1,88 +0,0 @@
-# Bridging messages between Waku v1 and Waku v2
-
-## Background
-
-The `wakubridge` application allows bridging messages between Waku v1 and Waku v2 networks.
-Packets received on the Waku v1 network are published once on the Waku v2 network using [`17/WAKU2-RELAY`](https://rfc.vac.dev/spec/17/).
-Similarly, Waku v2 messages received on the configured [`17/WAKU2-RELAY`](https://rfc.vac.dev/spec/17/) pubsub topic are bridged to the Waku v1 network.
-[`15/WAKU2-BRIDGE`](https://rfc.vac.dev/spec/15/) specifies how Waku v2 messages are converted to Waku v1 envelopes and vice versa.
-The `wakubridge` application follows the topic recommmendations for bridging as set out in [`23/WAKU2-TOPICS`](https://rfc.vac.dev/spec/23/#bridging-waku-v1-and-waku-v2)
-
-## Setting up a `wakubridge`
-
-Start by compiling the `wakubridge` binary.
-
-```bash
-# The first `make` invocation will update all Git submodules.
-# You'll run `make update` after each `git pull`, in the future, to keep those submodules up to date.
-make wakubridge
-
-# See available command line options
-./build/wakubridge --help
-```
-
-The next step is to run a `wakubridge` connected to both a Waku v1 and a Waku v2 network.
-
-### Connecting to a Waku v1 network
-
-Many [config options available for Waku v1 nodes](../../waku/v1/README.md) are also available for the `wakubridge`, with a slight change in the naming (most often a `-v1`-suffix).
-This includes configuration to connect to a peer or a fleet of peers.
-For example, to connect the bridge to the existing Status Waku v1 `test` fleet:
-
-```bash
-./build/wakubridge --fleet-v1:test
-```
-
-To connect the bridge directly to a static enode URL:
-
-```bash
-./build/wakubridge --staticnode-v1:<enode-url>
-```
-
-The `--staticnode-v1` argument may be repeated.
-
-### Connecting to a Waku v2 network
-
-Similarly, several [config options available for Waku v2 nodes](../../waku/v2/README.md) are also available for the `wakubridge`, with a slight change in the naming (most often a `-v2`-suffix).
-This includes configuration to connect to static Waku v2 peers:
-
-```bash
-./build/wakubridge --staticnode-v2:<peer-multiaddr>
-```
-
-The `--staticnode-v2` argument may be repeated.
-
-### Setting the Waku v1 and Waku v2 private keys
-
-It is possible to set the v1 and v2 node private keys for the bridge:
-
-```bash
-./build/wakubridge --nodekey-v1:<v1-private-key-as-hex> --nodekey-v2:<v2-private-key-as-hex>
-```
-
-### Configuration summary
-
-A typical `wakubridge` setup, combining the configuration items above, could look something like this:
-
-```bash
-./build/wakubridge --nodekey-v1:<v1-private-key-as-hex> --nodekey-v2:<v2-private-key-as-hex> --staticnode-v1:<enode-url> --staticnode-v2:<peer-multiaddr>
-```
-
-By default the `wakubridge` will then begin to bridge all Waku v1 messages routed by `staticnode-v1` to the Waku v2 network defined by the default Waku v2 pubsub topic (`/waku/2/default-waku/proto`) and participated in by `staticnode-v2`.
-Waku v2 messages on the default Waku v2 pubsub topic will similarly be bridged to Waku v1.
-This is the likely configuration for most `wakubridge` setups.
-
-### Other configuration
-
-For testing purposes, or for advanced bridging applications,
-it is possible to run the `wakubridge` application with a Waku v1 topic interest:
-
-```bash
-./build/wakubridge --waku-v1-topic-interest:true
-```
-
-It is also possible to change the default Waku v2 pubsub topic from/to which messages are bridged:
-
-```bash
-./build/wakubridge --bridge-pubsub-topic:/waku/2/my-bridge-pubsub-topic/proto
-```