Alby: a Lightning wallet bridge for the browser

What the extension actually is

The Alby browser extension integrates the Bitcoin Lightning Network into websites, enabling both payment and authentication flows, and it is described as a lightweight and efficient web extension that lets browsers interact with the Lightning Network programmatically. The README is careful about the scope, saying the extension focuses on web payments rather than advanced node management, in order to keep the user experience simple and intuitive. The description at the top of the repository is broader still, adding that it is a wallet interface to multiple Lightning nodes and a key signer for Nostr, Liquid and onchain use, so the extension carries keys for more than one kind of asset. The primary language is TypeScript, the licence is MIT, and the homepage points at the extension page of the project site.

WebLN is the interface, not a private API

Alby implements the WebLN standard, and the README describes it as providing a universal interface for websites to connect to Lightning Network nodes, request payments, invoices, signatures and logins, and enable a smooth web payment experience. The FAQ explains what WebLN is in slightly more depth, a library and set of specifications for Lightning apps and client providers to facilitate communication between apps and users' Lightning nodes in a secure way, providing a programmatic, permissioned interface for letting applications ask users to send payments, generate invoices to receive payments, and much more. That is the important architectural point. Because the interface is a published standard with its own documentation site, a site built on WebLN does not depend on this extension specifically, and that is what keeps the extension from becoming a lock-in.

Multiple backends, and the choice about custody

The feature list calls out multiple accounts, with support for different Lightning node backends such as LND, CLN and custodial options, and the WebLN section says the extension supports both custodial and non-custodial setups, making it flexible for different use cases. This is the design decision that matters most for a user. A non-custodial setup means the extension talks to your own node and the keys never leave it, at the cost of you running a node and keeping it reachable. A custodial setup means someone else holds the funds and you sign into their account, which is simpler and less private. The FAQ explains the reasoning behind the multiple-backend support, saying the goal is not to write a full interface for a Lightning node with all the channel management features, and that better management interfaces already exist, and that supporting several different backends, custodial and non-custodial, is the focus.

The features beyond plain WebLN

The key features list goes past the bare standard, and two entries are worth reading closely. Custom budgets and allowances enable auto-payments and payment streams, which is the mechanism a site would use to let you set a spending limit rather than prompting for every payment. Payment history and metadata let you track transactions with additional website metadata, so a payment carries the context of what it paid for. The rest of the list is breadth: full WebLN support for sending and receiving payments, generating invoices, signing and verifying messages and dynamic invoice creation. LNURL support covers LNURL-pay, LNURL-auth and LNURL-withdraw, which is the set of protocols that lets a browser talk to a Lightning service without the full WebLN handshake. And keysend payments let you send without an invoice, which matters for the tip-a-content-creator case where there is no invoice to present.

Native companions, and reaching a node behind Tor

The extension supports native connectors to native applications on the host computer, passing each call to a native application using native messaging, and the stated purpose is that this lets Alby connect to nodes behind Tor through that native proxy application. One such companion exists for Tor nodes. This is a genuinely interesting piece of architecture, because a browser extension running inside a browser cannot easily open a raw connection to a node that is only reachable over Tor, and a native messaging host can. The README describes the native messaging approach as supported generally, which is a useful extension point for any other native helper a user might need, and it is the answer to the obvious objection that a browser extension is a strange place to keep a Lightning wallet.

How the extension is built

The repository is a modern TypeScript web extension project with a lot of moving parts visible in the tree. The build is webpack with a script per target browser, and the environment variables NODE_ENV, ALBY_API_URL and TARGET_BROWSER are what select a development or production build for chrome, firefox or opera, with the full build running the three in sequence. The package metadata requires Node 20 or newer and yarn, and a few of the scripts show how the targets are wired:

    "build": "yarn build:chrome && yarn build:firefox && yarn build:opera",
    "package": "./create-packages.sh",
    "lint": "yarn lint:js && yarn tsc:compile && yarn format:fix",
    "test:unit": "jest",

The top level of the repository shows a `src/` directory, `tests/`, `scripts/`, `static/`, `build-utils/`, `doc/`, a `create-packages.sh` script for packaging, a `tailwind.config.js` and a `postcss.config.js` for styling, `jest.config.js` with a custom test environment, a `playwright.config.ts` for end to end tests, and a `webpack.config.js`. There is a `.husky/` directory for commit hooks, a `commitlint.config.js` and a `lint-staged.config.js` for staged checks. The architecture is documented as a diagram in the doc directory.

Where this is the wrong choice

The limits are worth stating plainly. First, the scope is deliberate, so if you want a node dashboard with channel management and liquidity views, this is the wrong tool, and the project says so itself by pointing you at other management interfaces. Second, the custody trade-off has no clean answer. A browser extension is a compromise, because a browser is a hostile place for a key, and the custodial option avoids that problem by handing the key to someone else. Third, the note that updating may require reconfiguring your wallet is a real operational wart, since it turns a browser update into a task rather than a non-event, and for an extension that auto-updates that is a recurring friction. Fourth, the Lightning network itself is the bigger risk surface, since a browser extension that can move money is a browser extension that can be targeted, and the project's own security file in the repository root reflects that awareness. And fifth, the WebLN ecosystem is still young, so a site that depends on it is depending on a standard that is not yet finished, and a payment that silently fails is a payment that never happens.

Editorial conclusion

Alby fits a developer building a website that wants to accept Bitcoin Lightning payments, or a user who wants the browser to be able to authenticate and pay without a separate wallet window, since the WebLN interface is standardised and the extension implements it. It is the wrong choice if you want a node management interface, because the project states plainly that this is not the goal, and it is the wrong choice if you need a self-contained wallet you control entirely, because a browser extension is a compromise on key custody. Before you deploy it, read the note that updating may require reconfiguring your wallet, and decide whether a custodial backend is acceptable to you. The last push was on 2026-10-21 with v3.15.0 released on 2026-09-17, and the licence is MIT.

Frequently asked questions

Official sources

1. getAlby/lightning-browser-extension on GitHub
2. License: MIT
3. Project website
4. README
5. Releases