CraysAlby Hub
Alby Hub is where Alby turns from a convenient browser wallet into personal payment infrastructure: a self-custodial Lightning hub, NWC service, app-connection manager, sub-wallet factory and bridge between Nostr apps and real money.
The wallet that turns apps into payment surfaces
Alby Hub is easy to underrate if you only look at the NWC ecosystem map and file it under "wallets." It is a wallet, yes, but that is too flat. The product is closer to a payment control room for a person, creator, small business, developer or family group that wants one Lightning source to serve many apps without letting those apps hold the money.
That is why it belongs in the App and Wallet infrastructure layer rather than only in a protocol explainer. A Nostr social client such as Damus, Amethyst, Primal or noStrudel can ask for a zap. A music app can ask for a payment. A website can ask for WebLN-style access. Alby Hub is the piece that can sit behind those requests, check the connection, apply the budget, talk to a Lightning backend and record what happened.
The key shift is simple: apps become payment surfaces, not custodians. Instead of depositing funds into every product that wants a Lightning balance, the user connects a wallet service and grants limited powers. That makes the user experience smoother, but it also makes permission design the heart of the product. If the connection model is sloppy, the whole promise becomes dangerous. If it is clear, the app ecosystem gets much more usable.
What Alby actually built
The public launch post from July 24, 2024 introduced Alby Hub as an open-source, self-custodial Lightning wallet with an integrated node, a NWC app-store and a web interface for managing funds and channels. The GitHub README is more direct: Alby Hub lets a user control a Lightning node or wallet from other applications that support NWC, and it is meant to run 24/7 so it can receive online payments and attach to a Lightning address.
That 24/7 detail matters. A mobile Lightning wallet can be excellent for manual payments, but many NWC use cases assume a wallet service that is reachable when an app sends a request. If a listener zaps a song, a website requests a payment, a subscription job runs or a client sends an invoice command, the wallet service has to be online. Alby Hub turns that always-on requirement into a product choice: run it yourself, run it on a server, run it on a desktop that stays awake, run it on supported node appliances, or pay for Alby Cloud.
The current docs describe Alby Hub as more than a Lightning wallet: it offers on-chain and Lightning deposits and withdrawals, sub-wallets, an app marketplace, in-app BTC purchases, Alby Extension and Alby Go support, developer APIs and agent skills. That bundle is not random. It is the outline of Alby's wider strategy: one self-custodial hub, many user surfaces, many developer entry points.
Alby the company and the pivot behind the Hub
Alby was already important in Nostr before Alby Hub because the Alby browser extension, Alby Account, WebLN work, Bitcoin Connect and Nostr Wallet Connect made Lightning feel usable on the web. The launch article says the company wanted open-source, self-custodial tools that could still be comfortable for normal people. That is the tension Alby Hub lives inside: self-custody without pretending that channel management, backup state and online availability are easy.
The Hub also tells the story of a product pivot. A custodial or account-centered wallet can give people convenience quickly. But Nostr's whole culture keeps asking who controls the key, who owns the money, who can revoke access and what happens when an app disappears. Alby Hub answers by moving more responsibility to the user while trying to keep the Alby interface and integrations. It does not remove trust in Alby entirely, especially when a person uses Alby Cloud, Alby Account services or Alby's hosted support. It does move the money-control boundary in a more self-custodial direction.
The public repository helps here. The project is Apache-2.0 licensed, has thousands of commits, ships release binaries and Docker images, and exposes the main service code, NIP-47 handlers, frontend, node backend integrations, transaction service and deployment scripts. That does not make every hosted dependency transparent, but it gives the serious reader enough surface to inspect what the product claims to be.
Nostr Wallet Connect is the product spine
Nostr Wallet Connect is the protocol spine of Alby Hub. The NWC site defines it as an open protocol for connecting Lightning wallets to apps. The pattern is deliberately simple: an app connection is created, the app sends encrypted requests through a Nostr relay, and the wallet service decides whether to act on those requests. NIP-47 documents the wallet-connect request and response flow, including payment methods, notifications and error handling.
Alby Hub is one of the most important real products built around that pattern. In the repository, the `nip47` folder is not decoration; the README describes Alby Hub as an NWC wallet service. Internally the service subscribes to relays, listens for whitelisted events from known app pubkeys, dispatches requests to a Lightning client abstraction and publishes notifications. In product language, that means a connected app can ask the Hub to pay an invoice, make an invoice, check balance or receive payment updates, depending on the permissions granted.
The Nostr part should not be confused with a public social identity requirement. NWC can be used by Bitcoin apps and websites without turning the user into a social poster. Nostr is the message transport and authorization layer. That is exactly why the map in the image is useful but incomplete: Alby Hub is listed under wallets, but the same infrastructure reaches social clients, music tools, ecommerce, agent workflows, web libraries and future products that do not look like Nostr apps at all.
Budgets, permissions and expiration are not nice extras
The app-connection model is the part readers should understand before they get excited. Alby's docs explain that connecting an app authorizes it to make and receive payments on the user's behalf. That is powerful. It is also why Alby Hub gives each connection a title, budget, budget-renewal setting, activity history and expiration state. A connection can be full access, limited access, time-bound or budget-bound.
This is the difference between a one-time invoice and a sustained relationship. If an app only shows an invoice, the user approves that payment. If an app has an NWC connection, it may be able to request payments later without the same manual scan-and-confirm dance. That is the whole UX improvement, and also the whole risk. Alby Hub's budgets and renewal cycles are the user's guardrails.
The best mental model is not "connect this app and forget it." The better model is "create a disposable payment capability." Give the app the minimum methods it needs, the smallest budget that matches the use case, the shortest useful expiration and a name you will recognize later. Then revisit the connection list. If an app disappears, a budget feels too large or a phone is lost, delete or tighten the connection. NWC is only user-sovereign when the user can actually review and revoke access.
The backend story is deliberately plural
The README says Alby Hub uses an embedded LDK-based Lightning node by default. That is an ambitious default because LDK is a library stack rather than a finished consumer wallet. Alby is wrapping the hard parts in a product. The same README says the Hub can optionally use external backends including LND, Phoenixd, Cashu and CLN, with the project inviting requests for more.
That plural backend model is important because there is no single perfect Lightning custody path. LND and CLN appeal to people already running serious nodes. Phoenixd lowers operational burden with a different tradeoff profile. Cashu changes the model again by introducing ecash-style custodial mint trust rather than direct channel management. LDK gives Alby the ability to ship an integrated node experience without forcing every user to bring infrastructure first.
The product consequence is that two people can both say "I use Alby Hub" while relying on very different money engines underneath. One may have private channels opened through an LSP. One may connect to an existing LND node. One may experiment with Phoenixd. One may use Cashu for app balances. A good Alby Hub article has to say this plainly because the phrase "self-custodial wallet" does not mean every backend has the same trust, liquidity and backup behavior.
Cloud convenience versus self-hosting
Alby Hub can run in desktop mode as a Wails app for Mac, Windows and Linux, or in HTTP mode through Docker, Linux and Mac server deployments. The README includes quick-start paths for Linux servers, ARM64, Raspberry Pi 4/5, Raspberry Pi Zero, Docker, Docker Compose, Fly.io, Render and source builds. That breadth is real, and it tells you the intended audience ranges from normal users to node operators and developers.
Alby Cloud is the convenience side. The docs say cloud hosting gives a one-click setup process, always-online receive behavior and priority support. The launch post positioned it as a way to avoid buying hardware or maintaining a node while still keeping the Hub self-custodial. That phrase needs care. If Alby hosts the machine and support layer, the user still needs to understand what Alby can and cannot access, how backups work, how the Hub is unlocked, what happens to payment availability and what subscription features depend on Alby services.
Self-hosting is not morally superior if the user cannot keep it online, back it up or update it. Cloud hosting is not automatically weak if the key model and operational boundary are designed well. The right question is practical: who controls the keys, where is the data, who can stop the service, how are channel states backed up, how are updates verified and what happens when the host, relay or Lightning backend is unavailable?
Sub-wallets turn one hub into many spending contexts
Sub-wallets are one of Alby Hub's most important product moves because they make the hub useful for more than one person or one mental budget. The docs frame them as wallets for yourself, projects, friends and family. The blog post about sub-wallets makes the same argument with the "Uncle Jim" idea: one technically comfortable person can help others get usable Lightning wallets without each person running a separate node.
That is powerful for creators, venues, families and small organizations. A band could separate merch, ticketing and fan tips. A cafe could separate staff wallet behavior from the owner's main reserve. A teacher could create small student wallets. A family member could give someone a Lightning address and budget without handing over the full node.
It is also a responsibility multiplier. If you create wallets for other people, you become part of their trust path. You may be helping them avoid a custodial platform, but you may also become their support desk, backup adviser and liquidity manager. There is no reason to romanticize this. Alby Hub makes shared wallet infrastructure easier; it does not make social custody decisions disappear.
Lightning addresses and Alby Account are useful but distinct
Alby strongly recommends linking an Alby Account during setup even though the docs say it is not technically required. The practical benefits are clear: a Lightning address, one-click extension connection, email notifications, better support and easier use with Alby surfaces. The app-connections docs also describe the Alby Account connection as important for Nostr identity, Podcasting 2.0, payment notifications and plan payments.
That distinction matters because a user may hear "self-custodial" and assume every feature is local. Some features are not only local. A Lightning address attached to an Alby Account, support notifications, cloud plan payments and account-linked app surfaces involve Alby's operated services. That may be a good trade for many people. It should still be named so a reader can decide knowingly.
For Nostr users, the identity piece is especially interesting. Alby sits at the meeting point of Lightning address, Nostr identifier, NWC connection and app login. That can feel wonderfully convenient when it works. It can also confuse boundaries. Your Nostr key, your wallet seed, your Lightning address, your Alby account and your NWC connection secrets are different objects. A safe user learns which one is being used before approving anything.
The developer surface is larger than the wallet UI
Alby Hub is also a developer platform. The README lists application deeplink options for `/apps/new`, including flows where the Hub creates a secret and flows where the client creates a secret and shares a pubkey for authorization. It documents query parameters for app name, pubkey, return URL, expiration, maximum amount, budget renewal, request methods, notification types and isolated connections. That is product design exposed as API design.
This matters for app builders because a good wallet connection should not make the user copy secrets across confusing screens. A client-created secret flow lets the app provide a public key, send the user to authorize it in the Hub and return with useful parameters after approval. Combined with the Alby JS SDK, Bitcoin Connect and the NWC docs, this gives web apps a path to Lightning payments that does not require every app developer to build wallet custody.
The repository architecture also shows developer concerns beyond happy-path payments. The transactions service sits between the Lightning backend and NIP-47 or internal API calls. The event publisher handles wallet and payment events. Error codes, permission-denied cases, notifications and failed-payment states are part of the design. That is a good sign. Payment software becomes real when it can explain failure.
Backups are the part users must not skip
Lightning backup is the sharp edge of any self-custodial Lightning product. A seed phrase is not the whole story when payment channels change state. Alby's docs push users to store a wallet recovery phrase offline during setup, and the blog has written specifically about automated spending-balance backups. The README also references static channel backups and Alby Account-connected backup flows.
A reader should leave this page with one plain rule: do not treat Alby Hub like a throwaway web account. If you run it, understand the recovery phrase, the Hub password, the working directory, the database, the channel-state backup model and the difference between on-chain recovery and Lightning-channel recovery. If you use Docker or a server, the persistent volume is not an implementation detail. It is where your state lives.
The risk is not only losing funds. It is losing confidence. A person who tries self-custody, skips backups and breaks a channel state may decide the whole category is impossible. Alby Hub's real success depends on making backup behavior boring enough that users actually do it. Until then, any article that sells the convenience without the chore is doing the reader a disservice.
What can go wrong
The first risk is over-permissioned app connections. A large budget, no expiry and broad methods may be convenient, but it gives an app or leaked connection secret more room to harm you. The fix is not panic. The fix is small budgets, renewal limits, clear names, method limits and regular review.
The second risk is operational uptime. If your Hub is offline, app connections that depend on it may fail. If your relay configuration is weak, NWC messages may not arrive reliably. If your Lightning backend lacks inbound or outbound liquidity, payments may fail even though the UI looks fine. Alby Hub can make these problems more legible, but it cannot remove the physics of Lightning.
The third risk is confusing self-custody with zero trust. You may control the keys while still depending on Alby Cloud, LSPs, relays, Boltz swap infrastructure, app stores, domain names, email notifications, fiat on-ramps, backend software and the client apps you connect. That is normal for internet money. The mature version of self-custody is not pretending dependencies vanish. It is knowing which dependency can fail and what you can do next.
How to test Alby Hub without fooling yourself
Start with a tiny amount of bitcoin and one low-risk app connection. Connect the Alby Browser Extension, Alby Go or a Nostr client that supports NWC. Give it a small budget and an expiration date. Send one payment, receive one payment, then inspect the activity inside Alby Hub. The goal is to learn the permission loop before you put meaningful money behind it.
Then test failure. Turn off the connected app. Tighten the budget. Delete the connection. Try to pay again and confirm it fails in a way you understand. If you are self-hosting, restart the Hub and confirm it comes back. If you are using a server or Docker, confirm the data volume persists. If you use a Lightning address, test receiving when the Hub is online and think through what happens when it is not.
Finally, test portability. Can you use the same Hub with a social client, a web app and a mobile wallet interface? Can you identify which connection spent which sats? Can you recover your mental model after a week away? Alby Hub is not only measured by whether one zap succeeds. It is measured by whether the user still understands their wallet after connecting many surfaces.
Why it matters for the Crays map
For Crays, Alby Hub is one of the pieces that makes Nostr less abstract. A profile, venue, creator page, app, ticketing flow or community experiment can talk about zaps all day, but somebody still needs a wallet surface that is available, permissioned and understandable. Alby Hub is one of the strongest candidates for that role because it combines NWC, Lightning, account services, sub-wallets and developer flows in one visible product.
It should not be treated as the only answer. Zeus, LNbits, Cashu tools, BTCPay, Phoenixd, CLN, LND, Minibits, Boardwalk Cash and others matter in their own lanes. The right ecosystem map shows alternatives. But Alby Hub deserves a long article because it demonstrates the main product pattern the Nostr payment world keeps circling: apps should request payment powers from user-controlled wallets, not become banks by accident.
The reader's takeaway is practical. If you want Nostr apps to feel like real internet products, study Alby Hub. It shows how a wallet becomes an app platform, how NWC moves requests through relays, how budgets make trust tolerable, how self-custody creates chores and how open-source payment infrastructure can still have an operated business around it. That is not a slogan. That is the work.
Sources worth opening
This article follows Alby's official docs, the public getAlby/hub repository, NWC documentation, release notes, blog posts and the adjacent wallet/backend projects that define Alby Hub's real trust boundaries.
- Alby Hub official site
- getAlby/hub GitHub repository
- Alby Hub README
- Alby Hub latest GitHub release
- Alby Hub guide: Introduction
- Alby Hub guide: Getting Started
- Alby Hub guide: App Connections
- Alby Hub guide: Sub-wallets
- Alby Blog: Introducing Alby Hub
- Alby Blog: App Connections
- Alby Blog: Introducing Sub-wallets in Alby Hub
- Alby Blog: Alby Hub posts
- Nostr Wallet Connect official site
- NWC documentation
- NIP-47: Nostr Wallet Connect
- Alby product site
- Alby JS SDK repository
- Bitcoin Connect
- WebLN guide
- Lightning Development Kit
- LND
- Core Lightning
- Phoenixd
- Cashu protocol
- Boltz
- Alby Docker package
- Alby support
- Alby feedback board
