This repo builds lnd in a completely reproducible, and auditable way, and packages it into radically minimal Docker containers provided for various CPU architectures and in various variants.

• All git-tags (and most commits) are signed by D8CA1776EB9265491D07CE67F546ECBEA809CB18
• All git-tags (and most commits) are opentimestamps-ed
• All builds are fully reproducible. Each Dockerfile builds lnd twice: once on Alpine, and once on Debian, and the result binaries are compared against each other before proceeding
• Each build produces binaries for: amd64, arm64v8, arm32v7, and arm32v6
• Some Docker Images are also provided in different variants, ex: monitoring (enables Prometheus monitoring), or experimental (enables options disabled by default)
• All architectures are aggregated under an easy-to-use Docker Manifest
• All git-tags are build automatically, and with an auditable trace
• Each successful build of a git tag pushes result Docker image to Docker Hub
• Each successful build of a git tag uploads result Go binaries to Github Releases
• Images pushed to Docker Hub are never deleted (even if lnd version gets overriden, previous one is preserved)
• All final images are based on Alpine for minimum base size
• All binaries are compressed with upx
• Each git-tag build is tagged with a unique tag number
• Each minor version is stored in a separate directory (for the ease of backporting patches)

NOTE: For an always up-to-date list see: https://hub.docker.com/r/lncm/lnd/tags

• v0.10.0 v0.10.0-root-experimental v0.10.0-monitoring v0.10.0-experimental
• v0.9.2 v0.9.2-root-experimental v0.9.2-monitoring v0.9.2-experimental
• v0.9.1 v0.9.1-root-experimental v0.9.1-monitoring v0.9.1-experimental
• v0.9.0 v0.9.0-monitoring v0.9.0-experimental
• v0.8.2 v0.8.2-monitoring v0.8.2-experimental
• v0.8.1 v0.8.1-monitoring v0.8.1-experimental
• v0.8.0 v0.8.0-monitoring v0.8.0-experimental v0.8.0-bitcoind-0.19
• v0.7.1 v0.7.1-monitoring
• v0.7.0
• v0.6.1
• v0.5.2

First pull the image from Docker Hub:

docker pull lncm/lnd:v0.10.0

NOTE: Running above will automatically choose native architecture of your CPU.

Or, to pull a specific CPU architecture:

docker pull lncm/lnd:v0.10.0-arm64v8

Then to start lnd, run:

docker run  -it  --rm  --detach \
    -v ~/.lnd:/data/.lnd \
    -p 9735:9735 \
    -p 10009:10009 \
    --name lnd \
    lncm/lnd:v0.10.0

That will runs lnd with:

• all data generated by the container is stored in ~/.lnd on your host machine,
• all data is created as owned by used with UID 1000
• port 9735 is reachable on the localhost for the peer-to-peer communication,
• port 10009 is reachable on the localhost for RPC communication,
• created container will get named lnd,
• that command will run the container in the background and print the ID of the container being run.

To issue any commands to a running container, do:

docker exec -it lnd BINARY COMMAND

Where:

• BINARY is either lnd or lncli, and
• COMMAND is something you'd normally pass to the binary

Examples:

docker exec -it lnd  lnd --help
docker exec -it lnd  lnd --version
docker exec -it lnd  lncli --help
docker exec -it lnd  lncli getinfo
docker exec -it lnd  lncli getnetworkinfo

After git-tag push, the release process is fully automated. That being said there are a few things that need to be done to prepare for the release.

In case of a patch release (v0.0.X), it's enough to edit VERSION variable in appropriate Dockerfile, commit, and run ./scripts/new-release.sh ….

Ex. If lnd gets updated from v0.6.0-beta to v0.6.1-beta, it's usually enough to open 0.6/Dockerfile, update this line with the new tag, commit, and run:

./scripts/new-release.sh v0.6.1

NOTE: The new-release.sh scripts ensures that correct version is set in the relevant Dockerfile, as well as that correct build tag is used.

This releases might bring changes that are not backwards compatible. To have separation, it's recommended to create MAJOR.MINOR/ directory at repo's root, copy Dockerfile from the previous version, and follow the steps described in Patch Release.

One additional thing to be done here, is adding a new entry to matrix.ver in test.yml file to make sure that newly added version is being tested.

To trigger build of new-multi arch release, run ./scripts/new-release.sh …. After a few minutes the new version should show up on Docker Hub.