The goal is to run c-lightning with plugins in a local testing cluster. For my cluster I use Simverse. Simverse allows for additional command line arguments to be passed to lightningd, so it should be possible to run lightningd with the plugin argument.

Let's first clone our plugin. We will be using one of the plugins that are available through Lightningd on Github.

cd ~\simverse\_repos
git clone https://github.com/lightningd/plugins.git --depth 1

We put the plugin in the _repos folder, because it is assumed that the plugin is there when the cluster is being build. (Also: throughout this article we assume your simverse folder is inside your home folder. If that is not the case, adjust it accordingly)

Since all nodes in Simverse run inside Docker containers, that plugin-file should be made available inside the Docker context folder. The _repos folder is not part of that context (each container gets its own context) so we have to copy the file from the _repos folder to the Docker context folder. Luckily Simverse works with the concept of recipes. A recipe describes how your cluster should look like. A recipe is a bash script that uses a library called cookbook that can be used to build your cluster step-by-step. Since it is "just" a bash script, you can do anything bash can do to tweak your cluster.

We will create a recipe that creates a cluster with three c-lightning nodes, running on a bitcoind back-end.

If you want to debug LND, or if you want to take a real deep dive into LND, you probably want to be able to set breakpoints in the source code to see what is actually happening. Not only that, you also want to have the node run in a local cluster of other nodes, so that you can perform some real Lightning actions like opening a channel and make payments. This post takes you through the setup I use based on Delve and Simverse.