CraysAlby
Alby is one of the reasons zaps stopped feeling like a protocol demo. It put Lightning, Nostr keys, browser payments and wallet connections close enough to the user that Nostr money could become a normal button.
The wallet layer that made zaps feel normal
Alby is not only a wallet and not only a Nostr tool. It is the bridge that made a strange idea feel ordinary: you can read a note, press a zap button, and send real sats without leaving the web page, scanning a QR code or teaching every social app how to become a Lightning wallet.
That sounds simple now because Alby helped make it feel simple. Before the wallet layer matured, Nostr money was easy to admire and awkward to use. A zap receipt is a signed Nostr event. A Lightning payment needs a wallet. A web app wants an interface. A user wants to support someone without opening four tabs. Alby sits in that collision and tries to make it behave.
NostrApps calls Alby "your bitcoin and nostr companion for the web" and points to Nostr Wallet Connect, Nostr authentication, the Chrome extension, zaps, sats and frequent maintenance. That description catches the user-facing shape, but Alby has grown beyond a single extension. The useful way to read it in 2026 is as a product family around one thesis: your wallet should be able to talk to many apps, while you keep more control over keys, budgets and custody.
That makes Alby especially important for Crays. If Nostr is going to support creators, venues, publishing, memberships, tips, small payments and real community rituals, the money button cannot be exotic. It has to become boring in the best sense: visible, understandable and limited enough that people are not terrified to press it.
Alby is several things, not one
Most confusion around Alby comes from treating the name as one app. It is better to separate the pieces.
Alby Extension is the browser layer. The official extension page says it connects Alby Hub and other Lightning wallets or nodes directly in the browser, lets users create and manage Nostr keys, supports app budgeting and connects web apps to payments. The GitHub README describes the extension as a Bitcoin Lightning browser extension with deep Lightning and Nostr integration, implementing WebLN so websites can request payments, invoices, signatures and logins. It supports multiple wallet backends and runs as a web extension, not as a full Lightning node manager.
Alby Hub is the wallet and node center. The Hub repository calls it "your own center for internet money" and says it lets you control a Lightning node or wallet from any application that supports NWC. It can run as a desktop Wails app on macOS, Windows and Linux, or as an HTTP/web app through Docker and server installs. Ideally, Alby says, Hub runs 24/7 so it can stay connected to a Lightning address and receive online payments.
Alby Go is the mobile companion. The Alby product ecosystem article says Go is a simple mobile wallet interface for Alby Hub and other NWC wallets, and that it can confirm new Hub app connections from a phone. It does not store wallet or Nostr private keys; it stores local connection secrets used to connect an NWC wallet.
Alby Account is the web account layer. It is optional, but it gives the user a lightning address, a Nostr identity path, notifications and a tipping page. For Alby Hub users, the account link can help route payments to the user's own wallet and, on supported plans, help with channel recovery. The account is not the same thing as the Hub, the extension or the user's Nostr key.
Nostr keys in the extension
The Nostr side of Alby starts with a practical problem: web clients need a signer. If you use a Nostr web app without a signer, the app may ask you to paste your private key. That is the habit Nostr needs to outgrow. Alby Extension became one of the common ways to keep that key in a browser extension and let websites ask for signatures through the familiar window.nostr pattern.
Alby's extension page says users can create and manage Nostr keys to log in and use decentralized social media. The product ecosystem article adds the sharper custody detail: Alby Extension can generate a Master Key that derives keys for Nostr, Liquid and on-chain Bitcoin web apps. If the user already owns Nostr keys, they can import them. Those keys are encrypted and stored locally on the computer and do not reach Alby's servers, according to Alby's own explanation.
That is a big claim because it tells the reader where the trust moves. Alby is not saying "we own your Nostr identity for you." It is saying the extension can hold the key locally and act as the signing surface for web apps. That still means you trust the extension, your browser profile, your device security and the update path. But it is much better than scattering your nsec into every experiment you open.
The extension is also a bridge between identity and payment. A Nostr client can use Alby for signing, while the same extension can connect to a Lightning wallet for WebLN and zaps. That pairing explains why Alby became so present in early Nostr culture. It solved two hard entry points at once: "How do I sign safely on the web?" and "How do I send sats from here?"
Alby Hub and NWC move the money home
The major shift in the Alby story is Alby Hub. Alby's documentation says the period of depositing funds in third-party apps is ending: let your wallet be the hub for payments and connect it to dozens of apps. The point is not only nicer UX. The point is custody.
Nostr Wallet Connect, or NWC, is the protocol underneath much of this. NWC describes itself as an open protocol to connect Lightning wallets to apps. After an app connection is created, the app can request payments through a Nostr relay. The wallet answers those requests. The app does not need to hold the user's bitcoin. That is why NWC feels like such a natural fit for Nostr: relays carry requests, keys authorize relationships, and the wallet remains its own actor.
Alby Hub is one of the important NWC wallets. The Hub README says it can use an embedded LDK-based Lightning node by default, or external backends such as LND, Phoenixd, Cashu and CLN. That gives very different users a path in. Someone can run a self-hosted Hub, run it through a cloud plan, or connect it to an existing node stack. The technical options matter because "self-custody" is not one shape. A creator with a laptop, a venue with a server, and a power user with an existing node do not need the same setup.
This is also why the old directory label "custodial" needs context. Alby historically had a shared wallet path, and many listings still remember that version. But Alby's own docs now push users toward Alby Hub replacing the integrated shared wallet. A good reading does not pretend every old Alby setup vanished overnight, but the direction is clear: Hub is the center of the current Alby money story.
Budgets are the secret user interface
The least glamorous Alby feature may be the most important one: budgets.
When an app connects to Alby Hub, it can be authorized to make and receive payments on the user's behalf. Alby's guide explains that connected apps can be given budgets, renewal intervals and expiration dates. The connection window tracks activity. If you pay through a connected app, the remaining budget goes down. If a connection expires, it stops working.
That is not just wallet administration. That is how small payments become safe enough to use often. A zap flow with no limits is scary. A zap flow where every 21-sat action demands a full wallet ceremony becomes annoying. Budgets create a middle ground: this app may spend up to this amount, for this period, and I can see what happened.
For Nostr, this matters enormously. Social money is not only "pay invoice." It is zaps on notes, zaps on streams, wallet-connected posting tools, podcasting, app stores, agents, small services and payment requests that appear while you are doing something else. If every one of those needs a QR code, people will stop. If every one of those can drain the wallet, people should stop. App budgets are the civilized compromise.
Alby Extension has a similar idea on the browser side with app budgeting and allowances. The exact surfaces differ, but the principle is the same: every connected site or app gets a boundary. That boundary is the feature that lets a user become generous without becoming careless.
The code and company trail
Alby is not a single weekend project. The public trail includes Alby Inc., the getAlby GitHub organization, the browser extension, Alby Hub, Alby Go, the SDK ecosystem and the Nostr Wallet Connect site.
The extension repository, getAlby/lightning-browser-extension, is MIT licensed and describes itself as a wallet interface to multiple Lightning nodes and a key signer for Nostr, Liquid and on-chain use. It lists WebLN, LNURL, Keysend, multiple accounts and budgets among its features.
The Hub repository, getAlby/hub, is Apache-2.0 licensed and more infrastructure-shaped. On June 6, 2026, GitHub showed more than 3,200 commits, with a Go backend, React frontend, Wails desktop app structure, NIP-47/NWC code, node backend support and deployment options. The README is clear that Hub can run as desktop software or as an HTTP app, and that it is meant to stay online if you want reliable Lightning address payments.
The product ecosystem article is also worth reading because it says what each Alby piece does not store. Hub does not store Nostr keys or Alby Extension passwords. Extension does not store wallet private keys. Go does not store wallet or Nostr private keys, but it does store NWC connection secrets locally. Those negative statements are valuable. Good wallet documentation tells you where the sensitive material is not, because that is how a user builds the right threat model.
How to test Alby without confusing the pieces
Start with the extension. Install it in a browser you already trust, create or import a test Nostr key, and use it with a Nostr web client that supports browser signers. Watch what the client asks for. If it signs a note, open that note from another client. That is the first portability check.
Then separate Nostr signing from Lightning payments. Signing a Nostr event and paying a Lightning invoice are different actions. Alby may make them feel close, but your risk model should not merge them. A Nostr key can damage identity. A wallet connection can move money. Both deserve attention, just not the same attention.
Next, test Hub with a small balance or a test setup. Create one NWC app connection, set a low budget, pay one tiny invoice from a connected app, then read the activity. Change the budget. Let a connection expire. Revoke it. You will learn more from that small loop than from any slogan about self-custody.
Finally, decide whether Alby Account helps your actual use. If you need a lightning address, notifications, a tipping page or easier Hub connection paths, it may be useful. If you only need a signer or a direct NWC wallet connection, you may not need the account layer. Alby is flexible enough that you can choose the pieces. The trick is knowing which piece you are choosing.
The best Alby setup is not the one with the most connected apps. It is the one where every app has a reason, every budget has a limit, every key has a recovery path, and you can explain where your sats live. That is when Alby stops being a confusing product family and becomes the payment layer Nostr always wanted.
Alby sources worth opening
Alby changes quickly, so read the current product pages and the protocol pages behind the payment flows.
