CraysAlby Cloud
Alby Cloud is the hosted version of the Alby Hub idea: keep the NWC wallet service online, make it reachable from apps, give the user a Lightning and Nostr address, and remove the server-maintenance chore without pretending hosting has no trust boundary.
The hosted answer to the always-on wallet problem
Alby Cloud exists because Nostr Wallet Connect and Lightning app connections are most useful when the wallet service is online. A local wallet that sleeps with your laptop can be fine for manual payments. It is less reliable for a Lightning address, an app connection, an automated zap, a creator tool, a point-of-sale experiment or a mobile app expecting the wallet to answer when asked.
Alby Hub solves the software problem: a self-custodial wallet service that can connect to apps through NWC. Alby Cloud solves the operations problem: where does that Hub run, who keeps it online, who handles the hosting path and how quickly can a normal user get to a working setup? The pricing page describes Cloud as the plan for people who want convenience and reliable hosting. That sentence is the product in miniature.
This is why Alby Cloud deserves a separate page from Alby Hub. The Hub is the engine. Cloud is the managed hosting lane for that engine. A self-hosted Hub and a cloud-hosted Hub can expose similar wallet and app behavior, but their operational responsibilities are different. That difference is where trust, price, support and recovery live.
What the current plan promises
As of this review, Alby's pricing page lists Alby Cloud as a paid plan and describes it as including Alby Hub 24/7 cloud hosting, a setup ready in under a minute, a link to access the node anywhere, custom Lightning and Nostr addresses, unlimited sub-wallets, encrypted remote backups, subscriber community access, a money-back guarantee and support for open source. Prices and plan details can change, so the durable point is the bundle rather than the exact sticker.
The bundle tells you what problem Alby thinks it is solving. People want the control and app-connection model of Alby Hub, but many do not want to run Linux, Docker, volumes, backups, DNS, uptime monitoring or a Raspberry Pi. Cloud moves those chores into Alby's service relationship while keeping the product tied to the Hub and NWC model.
For the reader, that means Alby Cloud is neither just a hosted custodial wallet nor a purely local self-hosting setup. It sits in the middle: the user is buying hosting and convenience for a self-custodial Lightning wallet service. That middle category needs careful language because it is easy to overstate either side.
Why NWC makes hosting valuable
Nostr Wallet Connect lets apps request wallet actions through encrypted Nostr messages. That makes wallet permissions portable across web apps, Nostr clients, mobile tools and future agent workflows. But it also assumes a wallet service that can receive those messages, evaluate permissions and respond. If the service is offline, the app experience weakens.
Cloud hosting makes NWC feel less fragile. A music app, social client, ecommerce surface or creator tool can rely on the wallet being reachable more often. That does not remove relay risk or Lightning liquidity risk, but it improves the basic availability story. For nontechnical users, that may be the difference between using NWC and giving up on it.
This is also why Alby Cloud appears in the NWC ecosystem map under hosted NWC nodes. It is not listed there because it is a social app. It is listed because it can keep the wallet side of app connections online. Correct routing matters: this belongs in Wallets and infrastructure, while the Apps hub should still surface it because app users need to find it.
The self-custody claim needs exact reading
Alby describes Hub as a self-custodial Lightning wallet. Cloud hosting does not automatically erase that, but it changes the operational context. The user needs to know what secrets Alby can access, what is encrypted, how the Hub is unlocked, how remote backups work, what happens if a subscription lapses and what recovery steps exist if the hosted instance is unavailable.
The pricing page names encrypted remote backups, which is a significant promise. Backups are the place many Lightning products become hard. A seed phrase is not always enough for channel state. A cloud product that handles backup flow can save users from common self-hosting mistakes, but the exact backup and restore path is still something users should read before keeping meaningful funds there.
The clean way to say it is this: Alby Cloud can reduce hosting and backup chores, but it does not make wallet literacy unnecessary. Users still need to understand spending permissions, NWC connections, sub-wallets, recovery phrases, passwords and the difference between Alby Account services and Hub wallet state.
Custom Lightning and Nostr addresses
The current pricing comparison says Alby Cloud includes custom Lightning and Nostr addresses. That matters because addresses are the public side of payment identity. A custom address is easier to share, easier to remember and easier to place in a Nostr profile, podcast page, creator bio or venue payment flow.
Nostr users know the problem: a raw public key is durable but unfriendly. A Lightning invoice is precise but temporary. A Lightning address and NIP-05 style identity make a person reachable in human terms. Alby Cloud packages that identity layer with the wallet hosting layer, which is powerful for creators and ordinary users alike.
The risk is dependency. A custom address depends on domains, account services and provider availability. If a user's public payment identity depends on Alby's infrastructure, the user should know what happens if they move away. The best products make exit paths clear: how to change addresses, update Nostr metadata, migrate Hub state and tell clients where to pay next.
Sub-wallets make Cloud useful for groups
The pricing page says Alby Cloud includes unlimited sub-wallets, while the free self-hosting tier is more limited. Sub-wallets matter because one wallet service can serve multiple contexts: a creator project, a family member, a small shop, an event team, a club, a venue or a developer test environment.
This is where Cloud can become attractive to nontechnical organizers. They may not want to run infrastructure, but they do want to give a team a Lightning address, cap spending, separate balances and keep payments organized. If Alby Cloud makes that simple, it becomes more than a convenience plan. It becomes small-scale payment infrastructure.
The social boundary must be explicit. If you create sub-wallets for other people, you are taking on a support and trust role. You may be helping them avoid a custodial app, but you may also become the person who explains lost access, failed payments, backup behavior and budget limits. Alby Cloud lowers the server burden; it does not remove the human burden.
Cloud versus a Raspberry Pi
Alby Hub can be self-hosted on servers, Docker, Raspberry Pi setups and other environments. That path gives technical users more control over the machine and storage. It also gives them more ways to make mistakes. They must understand persistence, updates, network reachability, reverse proxies, backup paths and system maintenance.
Alby Cloud trades some of that control for speed and reliability. A user pays Alby to keep the instance reachable and managed. That is not a shameful shortcut. It is a product decision. Many users who want Nostr payments do not want a weekend of server administration. The ecosystem needs both paths: the self-hosting path for people who can operate it, and the hosted path for people who want the behavior without the machinery.
The important thing is not to sell Cloud as magic sovereignty. Hosting always has a provider boundary. The useful question is whether the provider boundary is narrow, clear and reversible. A mature Alby Cloud user should know what they gain, what they outsource and what they can recover if they leave.
Where Alby Account enters the story
Alby Cloud is tightly connected to Alby Account because the hosted service, plan, access link, Lightning/Nostr address and support relationship need an account surface. The Account article explains that layer more fully. For Cloud, the point is simple: the paid hosted plan is not just software; it is a service relationship with Alby.
That relationship can be good. It gives users a place to log in, receive support, manage subscriptions, use addresses and connect other Alby products. It also means the account layer has to be secured. Email security, password handling, two-factor practices where available and clear recovery habits become part of wallet hygiene.
A person who wants maximum self-hosted separation may choose not to use Cloud. A person who wants reliable app connections may happily choose Cloud. The archive should not flatten those preferences. It should show what changes at the boundary between account service and wallet service.
Enterprise and venue implications
The pricing page includes an enterprise lane with custom requirements, automated liquidity management, enterprise-grade performance, dedicated onboarding and priority support. That matters for Crays because venues, communities and organizations often need something between hobby infrastructure and bank-grade operations.
A venue that wants Nostr zaps, creator payouts, local memberships or team wallets may not be ready to run a full Lightning operation. Hosted Hub infrastructure with support could become the practical bridge. It can keep app connections online, provide addresses and separate sub-wallets while still letting the team learn the wallet model gradually.
The risk is procurement fantasy. Enterprise words do not automatically solve accounting, regulation, incident response, access control or staff training. A serious organization should ask how roles are managed, how funds are recovered, how logs are exported, what support response looks like and how the service handles liquidity. Cloud hosting is the start of operational readiness, not the whole thing.
What can go wrong
The first risk is account compromise. A hosted service with account access and wallet management surfaces must be protected like money infrastructure. If a user secures it like a casual social login, convenience becomes exposure. The second risk is over-permissioned app connections. Cloud makes the wallet reachable; that makes app budgets and method limits more important, not less.
The third risk is misunderstanding outages. If an NWC app fails, the cause may be the app, relay, wallet service, Lightning backend, liquidity, LSP, address resolution or the hosted Cloud instance. Users need a debugging path. A good hosted product should make that path visible through status, logs, notifications or support.
The fourth risk is subscription dependency. If a user builds workflows around always-on hosting, custom addresses and unlimited sub-wallets, they should know what happens if they stop paying, migrate away or lose account access. Exit planning sounds gloomy until the day it is useful.
How to test Alby Cloud
Start small. Set up Cloud, connect one low-stakes app, create a tiny budget and send one small payment. Then receive through the Lightning address and inspect where the payment appears. Confirm that the access link works from another device. Confirm that Alby Go and the browser extension show the behavior you expect.
Next, test sub-wallets. Create one for a project or test user, fund it lightly and connect it to a small app. Make sure you understand who can spend, who can receive, how the sub-wallet appears in the dashboard and how you would disable it. The sub-wallet feature is only as safe as the user's ability to explain it.
Finally, test recovery language before you need recovery. Read the backup docs, identify the recovery phrase or backup path, understand the Hub password and confirm where encrypted remote backups fit. Do this before keeping meaningful funds in the system. Cloud hosting is most valuable when recovery is boring.
Why it belongs on the Hub
Alby Cloud belongs on the Apps hub because many Nostr apps become more useful when a wallet service is online. A user deciding between social clients, music tools, payment widgets and creator products needs to know where the wallet backend can live. Cloud is one answer.
It belongs in Wallets because its primary job is wallet infrastructure, not content or social interaction. It is the hosted environment for a payment hub. That classification keeps the map honest while still making the page reachable from `/nostr/apps/` as the user requested.
The strongest version of the conclusion is practical: Alby Cloud is for people who want the Alby Hub/NWC experience without becoming server operators. It gives convenience, uptime and support. It also adds hosted-service dependencies. Use it when that trade is worth it, and understand the boundary before you connect important apps.
Sources worth opening
This profile uses Alby's pricing and Hub pages, Hub documentation, public repository, NWC docs and adjacent Lightning/Nostr standards to explain what Alby Cloud changes compared with self-hosting.
- Alby pricing page
- Alby official site
- Alby Hub guide
- Alby Hub getting started
- Alby Hub app connections
- Alby Hub sub-wallets
- Alby Account guide
- Alby Go guide
- Alby Browser Extension guide
- Alby Hub GitHub repository
- Alby Hub README
- Alby Hub releases
- Alby Docker image package
- Nostr Wallet Connect
- NWC docs
- NIP-47 Nostr Wallet Connect
- NIP-57 Lightning Zaps
- NIP-05 identifiers
- Lightning Address
- LNURL LUD-16
- Lightning Development Kit
- Phoenixd
- LND
- Core Lightning
- Alby support
