# Polar: a local regtest Lightning network on your own machine

> Polar is an MIT licensed Electron desktop app that spins up regtest Bitcoin Lightning networks with LND, Core Lightning or Eclair nodes so payment applications can be developed and tested without touching mainnet. It is a heavy tool with a real Docker dependency, and it is a strong fit if your work is Lightning specific.

**jamaljsr/polar** — One-click Bitcoin Lightning networks for local app development & testing

- Repository: https://github.com/jamaljsr/polar
- Website: https://lightningpolar.com
- Stars: 861 · Forks: 186
- Language: TypeScript
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/jamaljsr-polar

## Regtest networks without hand-written docker compose files

Polar exists to remove the setup work that normally sits between a Lightning developer and a working test environment. The stated purpose is to help Lightning Network application developers quickly spin up one or more networks locally on their computers, and the project calls itself one-click Bitcoin Lightning networks for local app development and testing.

The scope of that promise is wider than a node launcher. According to the feature list, you can create a regtest Lightning Network in a few clicks, connect from your app to the lightning nodes via RPC, add nodes with drag and drop, start and stop individual nodes, open and close channels, create and pay Lightning invoices, launch a terminal in each bitcoin or lightning node, stream logs from each node, mine new blocks manually, deposit regtest coins into each Lightning node, mint and send Taproot Assets, and export or import networks so you can share a topology with another developer.

That list is the real product. The hard part of Lightning testing is rarely starting one daemon. It is keeping several daemons in a known state, funding them, opening channels between the right pairs and then being able to reset. Polar treats those as one workflow, which is why it sits in a desktop app rather than a library.

## LND, Core Lightning and Eclair in one topology

A Lightning network is not one implementation. Polar runs Bitcoin Core alongside several Lightning node daemons, and the supported version list is published explicitly: LND from v0.16.4 up to v0.20.0, Core Lightning from v24.08.1 up to v25.12, Eclair from v0.9.0 up to v0.13.1, Bitcoin Core from v26.0 up to v30.0, Taproot Assets from v0.3.3 up to v0.7.0, and Terminal from v0.14.1 up to v0.16.0.

Keeping three Lightning implementations in one network is the feature that most distinguishes Polar from running a single daemon in a container. It is also the reason the version lists matter, because behaviour differences between LND, Core Lightning and Eclair are where application bugs hide. Pinning the version list to a specific set of daemon releases also makes a shared topology reproducible, since you can export a network and hand it to a colleague who runs the same Polar version.

The Taproot Assets support is newer on the list, and it explains why the feature list mentions minting, sending and receiving assets and creating and paying Taproot Asset invoices. That is a separate asset layer running next to Lightning rather than a variant of it.

## Downloading the app and running it from source

The quick path is a desktop binary. You are directed to download Polar v4.0.0 for your OS, offering a dmg for Mac, and for Linux a deb, an AppImage and an RPM. Windows is covered by an exe. Alternative and older version binaries are found in the GitHub releases page.

Polar requires Docker to create the local networks. On Mac and Windows the recommendation is Docker Desktop, and on Linux you need Docker Server installed. If Polar cannot detect Docker it prompts you to install it.

Working from source is the path for packaging Polar yourself, fixing a bug or adding a feature, and the project points at CONTRIBUTING for details. The scripts in package.json are the toolchain entry points:

```json
    "dev": "concurrently --kill-others --success first \"yarn:dev:*\"",
    "lint:all": "yarn tsc && yarn lint",
    "package": "yarn build && yarn package:electron",
    "postinstall": "electron-builder install-app-deps && patch-package && husky",
    "test:all": "yarn test:ci && yarn test:e2e",
```

The README command table adds the rest: `yarn` installs dependencies, `yarn dev` runs the app with react hot reloading and electron live restarting, `yarn test` runs unit tests in watch mode, `yarn test:e2e` runs the end to end tests, `yarn lint:all` runs typescript and eslint syntax checking, and `yarn package` packages the app for your OS.

One detail worth noting if you build from source: the install step is not a plain dependency fetch. The postinstall script runs electron-builder install-app-deps, then patch-package, then husky, so native module rebuilds and patches are applied at install time. The first install on a fresh machine is therefore slower than a typical JavaScript dependency fetch.

## Docker Desktop is unsupported on Linux

The most concrete failure mode in the project is documented with a warning marker rather than buried in a troubleshooting page. On Linux, Docker Desktop is currently not supported because of a significant change in how it handles file sharing between host and container, and the tracking discussion is linked in issue 636. On Linux you are expected to install Docker Server instead.

That is a hard boundary, not a preference. A Linux developer who follows a colleague's Mac setup and installs Docker Desktop will hit file sharing behavior that the project has decided not to support, and Polar will not smooth it over.

A second constraint is the size of the thing. A Polar network is Bitcoin Core plus Lightning daemons plus containers, each with its own logs and a terminal attached. On a laptop with limited memory or a slow disk, a topology with many nodes is a different proposition from running a single bitcoind in regtest. The project does not publish resource requirements, so treat node count as something to grow carefully rather than all at once.

## Terminals, logs and mined blocks are the debug surface

The feature list is worth reading as a debugging surface rather than as a feature checklist. Two entries stand out for anyone working on a Lightning application: launch a terminal in each bitcoin or lightning node, and view streaming logs from each node. When a channel fails to open or an invoice fails to pay, you need the daemon output, and Polar keeps it attached to the node rather than behind a separate docker compose invocation.

Two more entries close the loop for payment testing. Manually mine new blocks is what makes regtest coins appear without waiting, and deposit regtest coins into each Lightning node is what lets you open channels from a funded wallet. Together with create and pay Lightning invoices, that covers the path most payment applications need to walk: fund a node, open a channel, create an invoice, pay it, and observe.

Export and import networks is the collaboration feature. A network you have configured can be shared with other Lightning developers, which saves both sides from rebuilding the same topology and lets a bug be reproduced from a known state. The custom node route extends this further: the project documents creating your own docker images to use as custom nodes, for example a master branch or a local fork, so you can test against a patched daemon build.

## An MCP server for driving simulations from an agent

Polar includes an MCP server, described as enabling AI agents like Claude and Cursor to programmatically control Lightning Network simulations. The details are not in the main README page. Installation instructions live in a separate repository, polar-mcp, and the technical details, including the architecture, the API, and how to add new tools to Polar, is in the MCP Architecture Documentation under docs.

The design has an obvious appeal for agent-driven development. An agent that can open channels, fund nodes and pay invoices against a local network can generate and verify scenarios without a human clicking through the UI for every run. The caveat is equally obvious: the feature is documented outside this repository, so treat the MCP surface as a moving target and read the architecture document before you build on it.

This is also the one place where Polar overlaps with plain scripting. If your test harness already drives bitcoind and lnd over RPC, the MCP server is an alternative interface to the same nodes, not a new capability. Whether it is worth the extra dependency depends on whether the agent workflow matters to you.

## An Electron shell, a versioned release line and an MIT licence

Polar is published under the MIT licence and the repository carries the MIT badge. That is a permissive grant and it means you can read, modify and redistribute the application, which matters for a tool that developers may want to run in a controlled internal setup.

The stack is a desktop application stack rather than a library stack. Node.js version >= 20 is listed, Electron as the cross platform desktop app framework, Typescript, ReactJS, Create React App, easy-peasy for Redux state management without the boilerplate, Emotion for CSS composition, Ant Design for the interface, react-i18next for multiple languages, electron-log for logging to console and file, and Jest with React Testing Library for tests. Build and release work is handled by Github Actions across Windows, Mac and Linux, with Renovate Bot handling dependency upgrades. Translations are managed on Crowdin, and the project notes that the initial translations of 10 languages were done by machine and are likely not fully accurate.

The release history shows v4.0.0 on 2026-01-06, v3.3.0 on 2025-06-20 and v3.2.0 on 2024-12-20. The repository is not archived and the last push was on 2026-10-18. Version numbers track the application itself, and the node version lists inside each release are the compatibility contract you should read when upgrading, because a new Polar release can add daemon versions your application has not been tested against.

## Conclusion

Adopt Polar when you are building on Bitcoin Lightning and need a repeatable regtest network with several node implementations, channel control and invoice flows on one desktop. Do not pick it for a single node, for public testnets, or if your team cannot run Docker on the developer machine. Check first that Docker is installed and reachable, that the node versions listed in the README match what your application targets, and that you accept that a full network is heavier than a single container.

## FAQ

### What does Polar require to run on my machine?

Polar requires Docker to create the local networks, and the engines field in package.json asks for Node.js version >= 20 when you build from source. On Mac and Windows Docker Desktop is the recommendation for Mac and Windows, while on Linux you need Docker Server because Docker Desktop is not supported there.

### Which Lightning node implementations does Polar support?

The README lists LND, Core Lightning and Eclair, each with a set of pinned versions, plus Bitcoin Core for the chain and separate versions for Taproot Assets and Terminal. You can mix implementations inside one local network.

### Can I use Polar to test Taproot Assets?

Yes. The feature list includes minting, sending and receiving Taproot Assets as well as creating and paying Taproot Asset invoices, and supported Taproot Assets versions are listed from v0.3.3 up to v0.7.0.

### How do I share a Lightning test network with another developer?

Polar supports exporting and importing networks for sharing with other Lightning developers. You can also build your own docker images to use as custom nodes, for example a master branch or a local fork, according to the custom nodes documentation.

### Does Polar have an MCP server?

Yes, Polar includes an MCP server that lets AI agents such as Claude and Cursor control Lightning Network simulations programmatically. Installation instructions are in the separate polar-mcp repository and the architecture is described in docs/mcp-architecture.md.

## Sources

- [jamaljsr/polar on GitHub](https://github.com/jamaljsr/polar)
- [License: MIT](https://github.com/jamaljsr/polar/blob/master/LICENSE)
- [Project website](https://lightningpolar.com)
- [README](https://github.com/jamaljsr/polar/blob/master/README.md)
- [Releases](https://github.com/jamaljsr/polar/releases)

---

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