# Lightning Terminal: a browser interface for running a Lightning node's daemons

> Lightning Terminal is a Go binary that bundles lnd, Loop, Pool, Faraday and Taproot Assets behind a single web interface on port 8443, so a node operator can see channels, move liquidity and earn sats from one place instead of five separate daemons.

**lightninglabs/lightning-terminal** — Lightning Terminal: Your Home for Lightning Liquidity

- Repository: https://github.com/lightninglabs/lightning-terminal
- Stars: 597 · Forks: 136
- Language: Go
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/lightninglabs-lightning-terminal

## One process instead of four daemons and three web interfaces

Lightning Terminal, abbreviated LiT, is described as a browser based interface for managing channel liquidity, and the project description is blunter: your home for Lightning liquidity. The feature list explains the appeal. You can visualise your channels and balances, perform submarine swaps through the Lightning Loop service, classify channels according to your node's operating mode, and use Pool to earn sats by opening channels to those needing inbound liquidity. The structural choice is the part that matters for an operator. Instead of running lnd, loopd, poold and faraday separately and reconciling three separate web interfaces, LiT runs a single binary that integrates the loopd, poold and faraday daemons, and it also gives you a preview release of the Pool UI. The audience is a node operator who has decided to run their own node rather than use a custodial wallet, and who wants the operational surface of a Lightning node to be one process and one URL.

## Running it locally and the password that matters

Installation is downloading the latest binary from the releases page, with detailed instructions on the docs site. Running it against a local lnd instance takes a single command.

```shell
⛰  ./litd --uipassword=UP48lm4Vjqxy<change_this_or_you_will_get_robbed>
```

The web interface is then on port 8443 over HTTPS, and the README notes that a password of at least 8 characters is required to run Lightning Terminal. It also gives the advice that in a production environment you should store this password as an environment variable to avoid it being recorded in the command history, which is a good catch given that the interface can move funds. The example password in the README is deliberately conspicuous, with a placeholder telling you to change it. For a remote lnd instance there is a separate document, docs/config-lnd-remote.md, and for replacing an existing lnd with the one integrated into LiT there is docs/config-lnd-integrated.md, so the two deployment shapes are documented separately rather than assumed.

## lnd must be built with every subserver

The requirement on lnd is the one that trips people up. LiT requires lnd to be built with all of its subservers, and requires at least version 0.11.0. The README gives the build tag to use if you compile lnd from source.

```shell
⛰  make install tags="signrpc walletrpc chainrpc invoicesrpc"
```

Each of those tags corresponds to a capability the interface needs. Without them the daemons that LiT drives have no way to talk to the node, and the failure will look like a missing feature rather than a build flag. The release binary of lnd is the other route, and the README points at the official releases page for that as well as the installation instructions for building from source. The requirement is stated in bold in the source, which tells you how often it has bitten people.

## Integrated, remote or disabled, and the combinations that fail

LiT operates in two modes for lnd, integrated and remote, and the same three-way choice applies to each of the additional daemons: Faraday, Loop, Pool and Taproot Assets, each of which can be configured as integrated, remote or disabled. The README is blunt that this creates many possible configurations and that not all combinations are supported due to technical constraints, and it publishes the matrix. Every daemon can be integrated in either lnd mode, and every daemon can be disabled in either mode. The remote daemon modes, however, work only when lnd is in remote mode, so a remote loop with an integrated lnd is not on the list. One more line covers lnd running in stateless init mode, which works with an integrated lnd and not with a remote one. A separate note records a functional limit: Taproot Assets channel functionality is only available when lnd and tapd run in the same process, which means lnd-mode=integrated together with taproot-assets-mode=integrated, and remote mode support is planned for the future.

## Upgrading from early versions and the lit.conf split

The upgrade story is short for most people and specific for anyone who started early. If you used command line arguments with previous versions, you do not need to change anything when upgrading. If you used v0.1.1-alpha or earlier, you need to create a lit.conf file in your LiT directory, and the default location depends on the operating system: ~/Library/Application Support/Lit/lit.conf on macOS, ~/.lit/lit.conf on Linux, and ~/AppData/Roaming/Lit/lit.conf on Windows. The migration is a matter of moving all the configuration settings specific to LiT from lnd.conf into lit.conf and removing any previous LiT specific customisations from lnd.conf, and the README adds that any section headers in the form of [ Example ] in lit.conf should be removed or changed to comments. The change exists because LiT now owns its own settings, and the split is the visible sign of that.

## The repository is a monorepo of a web app and a node manager

The top level entries explain the shape of the project. There is an app/ directory holding the web front end and app.go alongside app_noui.go for the version that runs without a UI, a cmd/ directory for the litd entry point, and separate packages for accounts/, autopilotserver/ and its rpc, db/, firewall/, firewalldb/, litrpc/, macaroons/, perms/, proto/, queue/, rpcmiddleware/, rules/, session/, status/, subservers/ and third_party/. The Makefile pins the reference Go version at 1.26.8, which the comment says is the version used for the release build, the Docker files and GitHub Actions and the one all other Go versions are checked against. The Dockerfile shows the two-stage build: a Node 22 alpine stage that clones the repository, checks out the requested tag, branch or commit, installs the app dependencies with yarn using a frozen lockfile, and builds the static assets, then a Go 1.26.8 alpine stage that serves them. The go.mod depends on lnd, loop, pool, faraday, taproot-assets and the Lightning Node Connect libraries, several of them at beta or alpha versions.

## Where Lightning Terminal is the wrong tool

The boundaries come from the packaging. The first is that this is an operations console, not a wallet, and not a custody solution, so the security model is the security model of a node you run on a machine you control, with a UI password that the README itself warns you to keep out of your shell history. The second is the moving parts. LiT pulls in lnd, loop, pool, faraday and taproot-assets, and the go.mod pins several of them at beta or alpha versions such as faraday v0.2.19-alpha, loop v0.35.0-beta, pool v0.7.1-beta and lnd v0.21.4-beta, so the dependency tree is not a set of stable contracts, and the compatibility table in the README exists precisely because the combinations break. The third is the operational scope: a browser interface on port 8443 with a self-signed certificate by default, which is why the README links to a Let's Encrypt configuration document for people running it on a remote machine. The alternative worth naming is running lnd with the individual daemons yourself and using each one's own interface, which is more moving parts for you but keeps each component independently versioned and independently replaceable. LiT is the right answer when the number of daemons has grown past the point where you can remember which port each interface is on.

## Conclusion

Adopt Lightning Terminal if you run a Lightning node and want one web interface over lnd plus the liquidity daemons, especially if you are not confident wiring up Loop and Pool by hand. Do not adopt it if you need a supported production setup, since the release notes, the daemon matrix and the bundled alpha dependencies all point at a tool that moves fast. Verify first which lnd version your release requires, since the compatibility table changes between releases, and read the supported combinations table before you pick integrated or remote mode for each daemon.

## FAQ

### What is Lightning Terminal and what does it bundle?

It is a browser based interface for managing channel liquidity, described as your home for Lightning liquidity. It runs a single binary that integrates the loopd, poold and faraday daemons, and it can visualise channels and balances, perform submarine swaps through Lightning Loop, classify channels by operating mode, and give access to a preview of the Pool UI.

### How do I run Lightning Terminal against a local lnd?

Download the binary from the releases page and run ./litd --uipassword with a password of at least 8 characters, then visit https://localhost:8443. The README recommends storing the password as an environment variable in production so it does not end up in your command history.

### What does lnd need to be built with for Lightning Terminal to work?

lnd must be built with all of its subservers, and must be at least version 0.11.0. If you build lnd from source, the README gives the command to enable the relevant subservers: make install tags="signrpc walletrpc chainrpc invoicesrpc".

### Which daemon mode combinations does Lightning Terminal support?

Each of Faraday, Loop, Pool and Taproot Assets can be integrated, remote or disabled, and lnd itself can be integrated or remote. The README publishes the matrix: integrated and disabled work for every daemon in both lnd modes, but the remote daemon modes require lnd in remote mode, and Taproot Assets channel functionality needs both lnd and tapd in the same process.

## Sources

- [Issues](https://github.com/lightninglabs/lightning-terminal/issues)
- [License: MIT](https://github.com/lightninglabs/lightning-terminal/blob/master/LICENSE)
- [lightninglabs/lightning-terminal on GitHub](https://github.com/lightninglabs/lightning-terminal)
- [README](https://github.com/lightninglabs/lightning-terminal/blob/master/README.md)
- [Releases](https://github.com/lightninglabs/lightning-terminal/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lightninglabs-lightning-terminal