CraysLNbits
LNbits is best understood as a Lightning wallet operating system: one funding source can back isolated wallets, API keys, extensions, payment tools and NWC connections for apps.
A wallet system, not one wallet
LNbits belongs in the wallet section, but calling it a wallet app undersells the thing that makes it useful. A normal wallet is where one person keeps money and sends payments. LNbits is closer to a wallet account system that can sit on top of a Lightning backend and carve that backend into many smaller wallets, keys, tools and app surfaces. The official project describes it as a free, open-source Bitcoin Lightning wallet accounts system, and the current README calls it a lightweight Python server on top of a Lightning funding source.
That architecture is why LNbits keeps appearing in builder conversations. A teacher can spin up temporary wallets for a workshop. A merchant can run a point-of-sale extension without handing the store the full node credentials. A developer can test a Lightning feature behind a clean HTTP API. A community can give members isolated wallets while keeping the server and funding source under one operator. Each wallet can have its own keys and limits, even though the funding rail may be shared.
For the reader, the key distinction is control boundary. LNbits does not magically remove the need for a real Lightning wallet, node, hosted backend or liquidity source. It organizes access to one. If the funding source is self-custodial, the operator still has node responsibilities. If the funding source is hosted, the operator inherits that provider's trust model. LNbits is the layer that makes accounts, extensions and app integrations manageable.
The funding source is the root
The most important LNbits decision happens before a user creates a pay link or connects a Nostr app: which funding source backs the instance. The docs use the terms backend wallet and funding source for the same thing. LNbits can keep users, API endpoints, extensions and configuration stable while the operator changes the backend through server settings. That makes the product flexible, but it also means the funding source is the root risk and root capability of the deployment.
The current funding-source documentation lists a wide spread of options. It includes self-managed node interfaces such as LND and Core Lightning, service-style options such as OpenNode and LNPay, newer choices such as Phoenixd and Breez SDK, and a Nostr Wallet Connect funding source. The comparison table separates custody, KYC, technical knowledge, hosting, privacy, liquidity management, setup difficulty, maintenance effort, cost and scalability. Those categories are more useful than a simple supported-wallet list because they show what a deployment is actually asking from the operator.
Readers should treat LNbits as a sharp tool here. Switching a backend can be operationally convenient, but it is not a cosmetic change. Settlement behavior, fees, privacy, liquidity limits, invoice handling and failure modes can change with the funding source. An LNbits wallet backed by a home node, an LNbits wallet backed by an NWC provider, and an LNbits wallet backed by a custodial service can look similar in the UI while carrying very different money risk.
Why isolated wallets matter
LNbits became popular because it solves a practical problem for Lightning builders: every app wants payment capability, but not every app should be trusted with the whole node. The README highlights per-wallet API keys as a way to keep individual applications away from the full balance. That is the basic LNbits pattern. Make a wallet for a purpose, give that wallet only the keys it needs, and let the server translate app actions into funding-source operations.
That split is helpful even when there is only one person using the instance. A developer can separate a test project from a public donation page. A store can separate a till from a back-office tool. A family or club can keep member wallets apart. A Nostr app connection can be created for a narrow job and removed later without rebuilding the whole Lightning stack. LNbits gives each small surface a place to exist.
Isolation is not the same as perfect security. The operator still needs to understand who can create wallets, who can install extensions, who can see or reset keys, and which server settings affect every user. LNbits can reduce blast radius if it is configured carefully. It can also concentrate risk if a casual operator enables too many extensions, exposes the server without care or treats every admin as fully trusted.
NWC works in both directions
The reason LNbits appears in the NWC ecosystem is not a vague association with Nostr. The LNbits news post on full Nostr Wallet Connect support says LNbits can now act as both a wallet service and a funding source via NIP-47. That matters because those are two different roles. In one role, LNbits is the wallet service that an outside app controls. In the other, LNbits is the client that uses some other NWC wallet service as its backend funding source.
As a wallet service, LNbits can expose one of its wallets to apps that understand NWC. A Nostr client, bot, point-of-sale tool or other application can receive a pairing URL, talk through relays, ask for invoices, pay invoices and check state according to the permissions and limits the user grants. This is the direction most readers imagine when they hear Nostr Wallet Connect: an app gets controlled access to a Lightning wallet.
As a funding source, LNbits can sit on top of an NWC wallet service. That means a public or hosted LNbits instance can be funded by another wallet that speaks NWC, including a private home instance or a different Lightning wallet service. The shape is subtle but powerful: NWC can be the bridge between where the money is controlled and where the LNbits app layer is convenient to reach.
The NWC Service Provider extension
The NWC Service Provider extension is the clearest reader-facing Nostr bridge for LNbits. Its README says it lets users connect LNbits wallets via NWC. The extension is now under the LNbits GitHub organization, with an MIT license and Python code. Its setup asks the operator to choose a relay path, then lets a wallet owner create connections with a description, optional expiry, permissions and limits. The output is a NWC pairing URL or QR code for the app.
The extension exposes the standard kinds of wallet actions a NWC user expects. Its permission file groups actions into sending payments, creating invoices, looking up invoice status, reading transaction history, reading wallet balance and reading account info. The task code registers handlers for methods such as pay_invoice, multi_pay_invoice, make_invoice, lookup_invoice, list_transactions, get_balance and get_info. Keysend methods appear in the permission grouping, while comments in the task registration show they are not currently supported by LNbits in that handler path.
That is the practical user story: choose a wallet, create a constrained connection, give the pairing string to an app, and revoke or adjust it when the app no longer needs access. A reader should not skip the constraints. The difference between invoice-only access and payment access is the difference between letting an app receive money and letting it spend money. Expiry dates, budgets and permissions are not decoration.
Relays become payment infrastructure
NWC is built on Nostr relays, so LNbits NWC use adds a network dependency that normal Lightning users may not be used to thinking about. The extension README offers two relay options. The easier option is a third-party relay that supports NWC connections. The other option is the LNbits Nostrclient extension, which can expose a WebSocket relay endpoint from the LNbits instance itself. The README notes that this Nostrclient route only works when the LNbits instance is publicly reachable.
The Nostrclient extension is more than a checkbox. Its README describes an always-on relay multiplexer that connects to multiple relays, rewrites subscription IDs to avoid conflicts, fans out requests and aggregates responses. That can make sense for an LNbits operator who wants more relay control, but it also creates another service to configure, monitor and protect. NWC payment reliability can now depend on WebSocket reachability, relay selection, relay liveness and how missed events are handled.
The NWC Service Provider README includes a warning about the handle_missed_events setting. A non-zero value can help process requests missed during downtime, but it can also create duplicate-payment surprises in shared deployments if users assume a request failed and pay another invoice elsewhere. That warning is worth taking literally. Payment messages are not timeline posts; replay and delay behavior can cost money.
LNbits can consume NWC too
The core LNbits repository contains an NWC wallet implementation under lnbits/wallets/nwc.py. The code describes it as a funding source that connects to a Nostr Wallet Connect service provider. It parses a nostr+walletconnect:// pairing URL, connects to the relay, requests the provider's info event, and calls wallet methods through encrypted NWC events. This is the other half of the bidirectional support announced by LNbits.
In that mode, LNbits is not exposing a wallet to an app. It is using an external NWC provider as the wallet beneath LNbits. The implementation checks whether methods such as make_invoice, get_balance and lookup_invoice are supported before relying on them. When a paid invoice needs to be tracked, LNbits can poll lookup_invoice if the provider supports it. If payment status cannot be queried, the behavior becomes less informative.
This is useful for readers who want a public LNbits layer without putting a full node or direct wallet credentials on that public server. A home Lightning setup can remain private while the reachable LNbits instance uses NWC to reach it. The benefit is separation. The tradeoff is that NWC support, relay reliability and provider method coverage become part of the funding-source reliability story.
Extensions are the superpower and the danger
LNbits is famous for extensions. That is where it becomes a toolkit rather than a plain account ledger. The extension-install guide explains that admins can configure extension manifests, install releases, enable extensions and later uninstall them. It also warns that extensions can have bugs or malicious code, and that administrators should use repositories they trust. That warning belongs near the top of any serious LNbits article.
The extension model is attractive because it lets people add Lightning features quickly. A project can ship a plugin with routes, templates, API endpoints, migrations and its own data model. The developer guide explains how an extension exposes public API routes under its plugin path and how migrations create database tables automatically. That is powerful for small teams, demos and communities. It is also a lot of code running beside money.
A careful LNbits operator should evaluate extensions like server software, not like browser themes. Check the repository, maintainer history, release notes, permissions, database migrations and network behavior. Install as few as necessary. Keep staging and production separate. If an extension gets access to wallet keys, payment creation, webhooks or admin-only paths, the risk is not theoretical.
Admin UI changed the operating model
Recent LNbits documentation puts major emphasis on the Admin UI. On a fresh install, the Admin UI is enabled by default, and first launch prompts the operator to create Super User credentials. With the Admin UI enabled, many settings are stored in the database and managed through the interface instead of being read from .env. If the Admin UI is disabled, the environment file becomes the central configuration source again.
This matters because LNbits is often installed by people who are comfortable with Lightning but not always with server operations. The Admin UI makes common configuration easier: switch funding sources, manage allowed users, promote or demote admins, gate extensions, disable extensions globally, adjust balances and customize the site. That convenience is real. It also creates a sensitive management surface that must be protected with strong credentials and careful exposure rules.
The Super User role is intentionally different from a regular admin. The docs reserve high-impact actions such as changing the funding source, restarting the server from the UI and crediting or debiting accounts for the Super User. Admins can handle much of the day-to-day work, but the funding rail should stay with the person ultimately responsible for the instance. LNbits is easier to run when roles are used as designed.
Running LNbits is real infrastructure
LNbits can be demoed quickly, but production use is infrastructure. The installation docs show several paths: AppImage on Linux, UV for developers, an install script, Nix, Docker, Fly.io, PostgreSQL, reverse proxies and systemd service setup. SQLite is the default database, while PostgreSQL is documented for operators who need a more robust database path. The project also publishes an AppImage release asset, with the latest GitHub release showing v1.5.4 as of April 23, 2026.
The install variety is helpful because LNbits is used in very different environments. A hobbyist can test locally. A teacher can run a workshop instance. A business can put LNbits behind a reverse proxy and proper TLS. A node operator can put it next to Core Lightning, LND or Phoenixd. The same flexibility makes operational discipline more important. Backups, database migrations, extension upgrades, funding-source credentials and authentication all need a plan.
The right mental model is not a disposable web app. LNbits can hold payment history, wallet keys, user accounts, extension data and connections to real funding sources. A reader should know where the data directory lives, how to restore from backup, which settings are in the database, which remain in .env, how logs are monitored, how updates are tested and how the instance is reachable from the internet.
The API is why builders keep returning
LNbits is not only a user interface. The developer docs point to Swagger documentation, and the README highlights the HTTP API as a way to integrate payments, wallets and accounting. For builders, that is the point. A wallet can become a programmable payment account with scoped keys, web-facing endpoints and extensions. The developer can build against LNbits without writing a Lightning backend from scratch.
This API layer is also why LNbits pairs well with Nostr tools. Nostr apps often need a wallet connection, but they do not necessarily want to become wallet software. LNbits can sit between an app and a funding source, or between an NWC provider and a collection of extensions. The app asks for a constrained action. LNbits translates that into the right wallet call. The funding source remains behind the account layer.
Builders should still test the exact methods they depend on. A funding source may support invoice creation but not the same status lookups. A NWC provider may support pay_invoice but behave differently around amountless invoices or error responses. LNbits can make the integration shape cleaner, but it cannot guarantee identical semantics across every backend.
Custody depends on deployment
LNbits is often discussed in self-custody circles, but the custody answer is not universal. LNbits can sit on top of a self-custodial node, a hosted provider, another LNbits instance, or an NWC wallet service. The comparison table in the docs exists because the funding source determines much of the custody and privacy story. The LNbits layer can isolate access, but it does not turn a custodial backend into a self-custodial one.
For an individual running LNbits at home on top of their own node, the main risks are server security, backups, liquidity, extension trust and key handling. For a hosted LNbits instance used by many people, the operator becomes a service provider with serious responsibilities. Users may see wallet balances inside LNbits, but they are trusting the operator and the funding-source setup behind that interface.
NWC adds one more custody nuance. A NWC connection is not a seed phrase, but a spending-capable pairing can be powerful. If a pairing URL grants payment permission and a budget, the app with that URL can attempt payments within those limits. Treat those strings like bearer credentials. Store them carefully, expire them when possible, and delete connections that are no longer needed.
Privacy is layered, not automatic
NIP-47 explains that NWC uses encrypted messages over relays and recommends unique keys for individual connections to avoid linking payment activity to a user's identity key. That design is better than asking every social app to hold wallet credentials, but it does not make all metadata disappear. Relays can still see event kinds, timing and tags. LNbits can still see wallet activity on the instance. The funding source can still see Lightning operations.
LNbits privacy therefore depends on several choices. Which relay is used for NWC? Is the relay third-party or self-controlled through Nostrclient? Is the LNbits instance public, private or behind Tor or a VPN? Which funding source backs the wallet? How many apps share the same NWC connection? Are logs retained? Are users sharing a hosted instance? Each layer adds or removes context.
The safest reader habit is to separate identities and connections by purpose. Do not reuse one high-privilege NWC connection for every app. Do not mix workshop wallets, merchant wallets and personal funds. Do not assume a relay choice is neutral. LNbits can help create smaller compartments, but the operator has to use them.
Where LNbits fits best
LNbits is strongest when a person or team needs many small Lightning surfaces without building a wallet backend each time. Workshops, demos, hackathons, small merchants, clubs, maker projects, Nostr apps, payment experiments and internal tools are natural fits. The system gives each project a wallet boundary, API keys and optional extensions while letting the operator choose the funding source that fits the moment.
It is also useful when the final architecture is still uncertain. A project can start with an easier funding source, learn the app flow, then move to a more controlled backend later. Because LNbits tries to keep apps and extensions stable while the backend changes, teams can separate product development from node operations. That does not remove migration work, but it can reduce early friction.
LNbits is less ideal for readers who want a simple consumer wallet with no server responsibility. It asks the operator to understand users, roles, extensions, funding, backups and updates. A hosted LNbits service can hide some of that work, but then the trust question moves to the host. The product rewards people who want a Lightning toolkit; it can overwhelm people who only want to zap a note.
What to check before using it with money
Start with the funding source. Confirm whether it is self-custodial, hosted, KYC-linked, liquidity-constrained or experimental. Test invoice creation, invoice payment, failed payments, fee behavior, expiry and refunds if your use case needs them. If NWC is involved, test pairing, relay reachability, permissions, budgets, expiry and revocation. Do not assume a successful demo payment covers every failure path.
Then check the operator surface. Is the Admin UI exposed only where it should be? Are Super User credentials strong and stored safely? Who can install extensions? Which extension manifests are trusted? Are admin accounts reviewed? Are logs monitored? Are backups tested? Is there a staging instance for upgrades? The answers matter more than the logo on the login screen.
Finally, check the user promise. If other people will use the instance, be honest about custody, support and limits. Tell users whether the operator can see or adjust accounts, whether balances are backed by a shared funding source, what happens during downtime, and how recovery works. LNbits can be a wonderful community tool, but shared money tools need plain expectations.
Project health and current signals
LNbits is active. The main GitHub repository was created in 2019, is MIT-licensed, and showed more than a thousand stars when checked on June 11, 2026. The latest release at that check was v1.5.4 - Hanzy, published on April 23, 2026. The release notes describe a minor release focused on an AppImage hotfix, UI fixes, dependency work and limits for users or extensions on service-style deployments.
The surrounding Nostr pieces are active too. The lnbits/nwcprovider repository was updated in June 2026, and the lnbits/nostrclient repository was pushed in June 2026. The open issue lists are small enough to inspect directly, including a feature request in nwcprovider about including a Lightning address in the NWC connection string when a wallet has a receive paylink. These are not guarantees, but they are useful signals that the work is not abandoned.
A reader should still check project health at the time of installation. Lightning software changes quickly, and LNbits sits at the intersection of server operations, payment infrastructure, extensions and Nostr protocol work. Review the current release, recent commits, security advisories, open issues, extension releases and docs before upgrading or deploying for other users.
The practical takeaway
LNbits is one of the most important pieces of Lightning app infrastructure because it gives small projects a way to use Lightning without each project becoming a wallet company. In the Nostr world, that becomes even more useful. A Nostr app can connect to an LNbits wallet through NWC, or an LNbits instance can be funded by another NWC wallet service. The same system can be a wallet service, app backend, account layer and extension host.
That versatility is exactly why it deserves careful handling. LNbits can make Lightning easier to distribute, but it can also put many payment surfaces behind one server. The best LNbits setups are boring in the good way: narrow permissions, trusted extensions, clear roles, tested backups, known funding sources, conservative NWC budgets and plain explanations for users.
For a reader deciding whether LNbits belongs in their stack, the question is not whether it is a wallet or an app platform. It is both. The better question is whether the reader needs a programmable Lightning account layer, and whether they are ready to operate the funding, server and permission model that comes with it.
Sources worth opening
Open the official LNbits site, docs, GitHub repository, NWC Service Provider extension, Nostrclient extension, current release notes, NIP-47, nwc.dev and the funding-source documentation before running LNbits or connecting it to apps.
- LNbits official site
- LNbits documentation home
- LNbits GitHub repository
- LNbits README
- LNbits latest release v1.5.4
- LNbits installation guide
- LNbits funding sources guide
- LNbits backend wallet comparison
- LNbits Admin UI guide
- LNbits Super User guide
- LNbits user roles guide
- LNbits extension install guide
- LNbits developer API reference
- LNbits extension developer guide
- LNbits extension repository
- LNbits NWC wallet source
- LNbits Nostr service source
- LNbits Nostr utilities
- LNbits NWC wallet tests
- NWC Service Provider repository
- NWC Service Provider README
- NWC Service Provider permissions
- NWC Service Provider API routes
- NWC Service Provider task handlers
- Nostrclient repository
- Nostrclient README
- LNbits full NWC support announcement
- LNbits with Nostr Wallet Connect article
- Nostr Wallet Connect official site
- NIP-47: Nostr Wallet Connect
- Raw NIP-47 specification
- Awesome NWC list
- LNbits logo asset
- LNbits old extension wiki link
- LNbits demo API docs
