LNbits connects Lightning backends with isolated wallets, APIs and extensions. A guide to architecture, use cases, self-hosting and security.
Roland Schellhorn
LNbits is a free, self-hostable platform for applications on the Bitcoin Lightning Network. It sits between a funding source—such as your own Lightning node or a supported wallet backend—and applications that send, receive or manage payments. Websites, apps, machines and merchant systems therefore do not need direct access to the complete node interface.
The official LNbits project description highlights three core building blocks: isolated wallets, per-wallet API keys and an extension system. LNbits does not replace Bitcoin or the Lightning Network. It is an application and account layer above an existing funding source.
Technically, LNbits is a lightweight Python server with a web interface and HTTP API. One instance can manage several users and logically isolated wallets. Each wallet has separate keys for read-only or administrative API access. Applications can work only with their assigned account instead of receiving access to all underlying liquidity.
This separation is particularly useful when shared Lightning infrastructure serves several projects: an online store, a point-of-sale terminal, a donation page, a workshop or an internal prototype. Accounts can be analyzed independently and replaced separately when necessary.
A typical architecture consists of three layers:
LNbits supports several backends. According to the official backend-wallet overview, the funding source is selected through configuration. A backend can be changed without fundamentally rebuilding applications, endpoints and extensions. Whether a particular production migration is seamless still depends on data, versions, liquidity and the selected backend.
An LNbits wallet is a separated account inside the instance. Each wallet has API keys with different permissions. This reduces the access scope of an individual application. Compromised credentials are still a security incident: keys must be stored like secrets, reviewed regularly and replaced when compromise is suspected.
The API can create invoices, inspect payments and process transactions. LNbits can therefore provide a common payment layer for web applications, mobile apps, devices and automations. Webhooks and extensions support event-driven workflows.
Features outside the core are installed as extensions. This keeps the base smaller and allows an instance to be tailored to its use case. The LNbits extension-installation documentation explicitly warns against arbitrary sources: extensions can contain bugs or malicious code. Administrators should configure trusted repositories only, review versions and test updates first.
Suitable extensions can implement LNURL payment and withdrawal flows, point-of-sale applications, vouchers and other Lightning services. Whether a feature is production-ready for a specific use case depends on the extension, version and operating model.
The official installation guide documents AppImage, UV, an installation script, Nix and Docker, among other options. SQLite is the default; the documentation points to PostgreSQL for higher-load applications. Docker deployments must persist data and extensions through volumes or they may be lost when a container is replaced.
Production installations need a reverse proxy, TLS, database backups, persistent storage, monitoring and a controlled update process. Extensions should be tested and updated together with the core. The documentation also recommends using the SuperUser only for initial setup and critical instance configuration; routine operations should use separate admin or regular accounts.
LNbits can segment access, but it does not remove custody and operational risk. Anyone operating an instance for other people or organizations assumes responsibility for availability, access control, backups, updates and the underlying funding source. Regulatory and tax obligations may also apply depending on the business model and jurisdiction.
Important measures include:
LNbits is particularly useful as a flexible wallet, API and extension layer. BTCPay Server focuses more strongly on complete merchant and checkout workflows. Direct node integration provides maximum control but requires more custom development and security work.
The right choice is not determined by a feature checklist alone. Custody model, user count, payment volume, required extensions, team expertise and operational responsibility all matter. A combination can also make sense: a specialized checkout platform for the store and LNbits for internal wallets, prototypes or additional Lightning services.
LNbits is compelling when several Lightning applications need a common technical base, wallets must be isolated or an API-driven prototype needs to be built quickly. A smaller solution may be sufficient for one simple payment destination. Regulated custody, significant balances or business-critical payment infrastructure also require a robust security, compliance and operations model.
BIT62 supports architecture, self-hosting, Lightning backend integration, API connections, custom extensions and secure operations with backups and monitoring. A clear separation between the funding source, LNbits instance and connected applications is the right starting point.
If you are evaluating LNbits for a store, app, machine or internal Lightning platform, we can assess requirements, risks and the operating model together.
Separate accounts and API keys limit each application's access.
Integrate Lightning payments into websites, apps, devices and automations.
Add LNURL, merchant and specialized capabilities to a lean core.
Connect invoices, point of sale and payment confirmation to your workflows.
Abstract supported Lightning backends behind a stable application layer.
Plan persistence, backups, monitoring, roles and updates professionally.
BIT62 helps with self-hosting, funding-source connections, API integrations, extensions, backups, monitoring and secure operations.