This page deploys a self-contained network of [logos-delivery](https://github.com/logos-messaging/logos-delivery) nodes (the `wakunode2` binary, distributed as a Docker image) on a single machine. It requires `docker` and `docker compose`. Configuration is exposed through environment variables — if a knob you need is missing, PRs are welcome.
-`LD_IMAGE` — the `logos-delivery` Docker image that every node will run. The image is still published under the legacy `wakuorg/nwaku` namespace (see [the upstream container build](https://github.com/logos-messaging/logos-delivery/blob/master/.github/workflows/container-image.yml)); pin a tag for reproducible runs.
-`NUM_LD_NODES` — number of `logos-delivery` nodes to launch (default 5; upper bound around 200 depending on host resources).
-`RLN_RELAY_EPOCH_SEC` and `RLN_RELAY_MSG_LIMIT` — RLNv2 parameters that cap how many messages each node may publish per epoch.
-`TRAFFIC_DELAY_SECONDS` and `MSG_SIZE_KBYTES` — used by the bundled `rest-traffic` injector to drive load through each node's REST API.
Once the network of `logos-delivery` nodes is up and running we can use it to perform different tests, connecting other nodes that we fully control with specific characteristics. This ranges from connecting spammer nodes, light clients, store nodes, and in the future unsynced nodes, etc.
Now that we have the network deployed we can use it. Hereunder we describe how to use the network deployed by `logos-delivery-simulator` to perform end-to-end tests of any desired feature. Each tutorial below targets a specific protocol from the [logos-delivery](https://github.com/logos-messaging/logos-delivery) suite:
⚠️ For every use case, ensure that your node is configured in the same way as the rest of the nodes, otherwise messages may be lost. Note that it can be also an intended test, seeing how the network reacts to other nodes connecting to it.