Nodana
Nodana is not a wallet by itself. It is a hosted app platform that can run wallet and Lightning infrastructure for you, so the real question is which template you deploy, who controls the keys, how access is protected and how you test the NWC connection before funding it.
What Nodana really is
Nodana is a cloud hosting service for Bitcoin applications. Its own introduction post calls it a one-click hosting service that takes the hassle out of configuring, deploying and running Bitcoin apps. The homepage uses the same practical language: deploy apps in the cloud in minutes, with no personal details or credit card required.
For a Nostr Wallet Connect reader, that sentence needs one careful addition. Nodana is not the wallet protocol. It is not Alby Hub, Phoenixd, LNbits, Cashu or Boltz. It is the hosted surface where some of those services can run. If a Nostr app connects to a wallet through NWC, the wallet service may be Alby Hub; Nodana is the place where that Hub is hosted.
That makes Nodana useful and risky in the same way all hosted infrastructure is useful and risky. It can save you from provisioning a VPS, installing Docker, wiring domains and keeping a server reachable. It also means a third-party platform is now part of the operational story for your Lightning wallet service, Cashu mint, swap daemon or backend tool.
Read Nodana as a convenience layer for people who want the benefits of always-on Bitcoin infrastructure without becoming full-time server operators. Then evaluate every deployment as infrastructure with money-adjacent secrets, not as a harmless website account.
Why it belongs in NWC Nodes in a Cloud
The Apps hub places Nodana under NWC Nodes in a Cloud because the product helps users run NWC-capable wallet infrastructure without hosting every piece locally. The most obvious example is the Nodana template for Alby Hub and Phoenixd. That template deploys Alby Hub with an automatically configured Phoenixd node.
Alby Hub is the actual NWC wallet service in that pairing. The Alby Hub repository says Hub lets users control their Lightning node or wallet from any other application that supports NWC. It can connect apps such as Damus or Amethyst and many more listed around the NWC ecosystem. Nodana supplies the hosting wrapper.
Phoenixd is the Lightning backend in the combined template. Nodana describes Phoenixd as a Lightning node with zero configuration, no channel management, no peer management, no liquidity management and no firewall configuration. That is a strong fit for users who want an always-on wallet backend but do not want to manage channels manually.
The category name should not overpromise. Nodana does not automatically make every hosted app an NWC node. It offers templates that can host wallet services, Lightning backends and Bitcoin tools. The NWC claim is strongest when the deployed service is Alby Hub or another service that explicitly exposes NIP-47 wallet connections.
The current template shelf
The Nodana homepage checked on June 14, 2026 listed several available templates: Alby Hub, Boltz Client, CDK Mintd, Fedimintd, Gatewayd, LNbits, Opencode Server and Phoenixd. The same footer links also expose templates for Alby Hub, Boltzd, CDK Mintd, Fedimintd, Gatewayd, LNbits, Nutshell, Opencode and Phoenixd.
For this page, the most relevant templates are Alby Hub, Alby Hub with Phoenixd, Phoenixd, LNbits, LNbits with Phoenixd, CDK Mintd, Nutshell and Boltz Client. Those are the templates that touch wallet service behavior, Lightning routing, ecash, mint operations, swaps or payment infrastructure.
The individual pages include useful operational clues. Nodana's Alby Hub page showed version 1.22.2, `ghcr.io/getalby/hub`, an Alby Hub link and a price of ten dollars per month. The Alby Hub with Phoenixd page showed version 1.22.2 plus Phoenixd 0.8.0 and a price of fifteen dollars per month. The Phoenixd page showed `nodana/phoenixd` version 0.8.0.
Those details matter because template hosting is not just a brand name. You should know the image, version, upstream project, price, update timestamp and service boundary before funding the app. A page that says Alby Hub and Phoenixd is different from a page that says LNbits and Phoenixd, and both are different from a Cashu mint.
Alby Hub on Nodana
Alby Hub is the cleanest Nodana use case for a Nostr reader. Nodana describes Alby Hub as an open-source, self-custodial Bitcoin Lightning wallet and an easy-to-use Lightning node for everyone. It highlights app connections such as Alby Browser Extension and Alby Go, sub-wallets for family and friends, control of funds and developer-ready APIs.
Alby Hub's own README explains the NWC role more directly. Hub allows a user to control a Lightning node or wallet from applications that support NWC. It can run as a desktop app or as an HTTP web app on Docker, Linux, macOS and other targets. Ideally, it runs all the time so connected apps can request wallet actions when needed.
Hosting Hub on Nodana can therefore be attractive. A user who does not want to run a home server can still have an always-on Hub URL, pay Nodana by Lightning and connect Nostr apps through NWC. That lowers friction for creators, small communities and developers testing NWC-powered apps.
The security question becomes hosting discipline. Where is the Hub data stored? How are admin credentials protected? How do you back up the wallet state? How do you rotate or revoke NWC connections? How do you recover if the Nodana app is deleted, suspended, migrated or upgraded? Nodana simplifies deployment, but it does not remove the wallet questions.
Alby Hub with Phoenixd
The combined Alby Hub and Phoenixd template is Nodana's most direct cloud-node story. The template page says that deploying it gives you Alby Hub with an automatically configured Phoenixd node. That means the user gets a wallet service and a Lightning backend in one hosted deployment pattern.
Phoenixd is designed to reduce Lightning node operations. ACINQ's phoenixd project describes it as the server equivalent of the Phoenix mobile wallet. Nodana's template text emphasizes zero configuration and no channel, peer, liquidity or firewall management. That is exactly why it pairs well with Alby Hub for people who want NWC without a full node-operator routine.
The tradeoff is service composition. Phoenixd can abstract away channel management, but it has its own model, fees, liquidity behavior, API, backup expectations and ACINQ-related assumptions. Alby Hub then adds NWC permissions, sub-wallets, app connections and user-facing wallet management. Nodana hosts both.
Before using the combined template for real funds, test it as a three-layer system. Confirm Phoenixd can receive and send. Confirm Alby Hub sees the backend. Create a low-budget NWC connection. Pay and receive tiny invoices. Restart the hosted app if Nodana exposes that control. Then document recovery before treating it as an everyday wallet.
LNbits on Nodana
Nodana also hosts LNbits. The LNbits template page calls LNbits a powerful suite of Bitcoin tools and a wallet accounts system accessible on all devices. It notes that LNbits can run on any Lightning Network funding source and that extensions add extra functionality.
LNbits is different from Alby Hub. It is not simply a personal NWC wallet service. It can be a wallet account system, a development platform, a custodial service surface for others, and an extension host. That makes it powerful, but also easier to misconfigure. API keys, admin access, extensions and funding sources all matter.
Nodana's LNbits with Phoenixd template adds another combined deployment option. It deploys LNbits with an automatically configured Phoenixd node. That can be useful for a developer who wants a hosted Lightning tool suite quickly, especially for tests, demos or small controlled services.
The reader should not assume LNbits on Nodana has the same trust model as Alby Hub on Nodana. LNbits wallets, extensions, invoice keys, admin permissions and user account boundaries deserve their own review. If LNbits is used for other people's funds or app accounts, the operator responsibility is higher.
Cashu and ecash templates
Nodana's CDK Mintd and Nutshell templates show that the platform is not only about Lightning nodes. It can also run Cashu-related services. The CDK Mintd page describes a Cashu mint daemon for the Cashu Development Kit and explicitly says the service uses `fakewallet`, making it suitable for developers who want to test against a publicly available mint.
That caveat is essential. A fakewallet mint is not a production money service. It is useful for development, integration testing and learning how Cashu wallets interact with mints. It should not be marketed to users as a safe place to hold value.
The Nutshell page is more general and includes a strong upstream-style disclaimer: the author is not a cryptographer and the work has not been reviewed, so a fatal flaw may exist. It also explains that Cashu mints are Lightning node runners acting as custodians for sats while issuing ecash to users.
If you run Cashu infrastructure on Nodana, separate development from production. Test mints are great for app builders. Production mints carry custodial, legal, liquidity, security and reputational obligations. Nodana can run the service; it cannot make a mint trustworthy by hosting it.
Boltz Client and swaps
Nodana's Boltz Client template widens the map from wallets to swaps. The page describes Boltz Client as a daemon that connects to the Boltz API to create and execute swaps. It can run in standalone mode and expose a REST API, with gRPC noted as coming later on the page checked for this article.
Boltz itself is a non-custodial Bitcoin bridge for swaps between layers such as Lightning and Liquid. That means a Nodana-hosted Boltz Client is not the same thing as a Lightning wallet. It is a tool for executing swap workflows through a daemon and API.
For Nostr and NWC readers, the relevance is indirect but practical. Wallet services and Lightning apps often need liquidity movement, submarine swaps, channel funding or layer transitions. A hosted swap daemon can sit beside Alby Hub, LNbits or a Phoenixd deployment in a project.
The test is again concrete. If you deploy Boltz Client, check API authentication, endpoint exposure, credentials, supported swap directions, logs, funding assumptions and what happens when a swap is interrupted. Do not expose a daemon API publicly without understanding its authentication model.
Login, payments and account surface
Nodana's FAQ says there is no separate register flow. New and current users log in to start using Nodana, with supported login methods listed as Nostr, Lightning and GitHub. It also says users top up balance with a Lightning wallet or WebLN provider such as Alby's browser extension.
That is why Nodana feels native to this ecosystem. It does not ask for a credit card to begin. The homepage says no personal details or credit card are required. The introduction post says payments are made over Bitcoin Lightning and billing is per-minute, with no contracts or long-term commitments.
This is useful for privacy-minded builders and small operators. It also means the user's operational account may depend on Nostr, Lightning or GitHub access. If you use Nodana for wallet infrastructure, make sure you understand how you regain account access if a signer, Lightning wallet or GitHub account becomes unavailable.
A good setup note should include the login method used, the notification channel, the top-up process, project names, app names and emergency contact path. Wallet infrastructure should not depend on memory alone.
Security claims to verify
Nodana's FAQ and security page make several concrete claims. The FAQ says Nodana does not store passwords or credit-card details, that apps run in sandboxed environments, are accessed over HTTPS only, and that only apps within the same project can communicate with each other.
The security page repeats the personal-data point and adds rate limiting, network-level authentication for apps that require it, and private internal networking for each project. It says all apps are rate limited to sixty requests per minute to help ensure an app is not abused.
Those are useful platform promises, but they are not a substitute for app-level security. If Alby Hub, LNbits, Phoenixd, Boltz Client or a Cashu mint has an admin panel, API token, seed phrase, database, macaroon, mint key or wallet backup, that app-level secret still needs care.
Verify the service from both sides. Open the public URL and confirm HTTPS. Check whether the app requires authentication. Confirm internal apps can talk only where intended. Understand rate limits before building production flows. And never assume sandboxing protects a wallet from leaked admin credentials.
Backups and updates
Nodana's homepage says every hosted app receives daily backups, regular updates and rate-limit protection. The product also says service updates can be applied with a single click when a new version of an app you run is available.
That sounds reassuring, but wallet infrastructure needs more than a generic backup claim. You need to know what exactly is backed up, how often, how restores are requested, whether backups include secrets, whether encrypted backups exist, and whether a restore preserves wallet state, LNbits databases, Cashu mint data or Phoenixd state correctly.
Updates deserve the same attention. A one-click update is convenient until a wallet service changes database format, a backend API changes, an extension breaks or a template version lags behind upstream. The safer pattern is to read upstream release notes before updating payment infrastructure.
For each Nodana app, write down the current template version, upstream release, data state, backup expectation and rollback story. The hosted model saves time only if you can recover calmly when the hosted app fails, updates badly or needs migration.
NWC permissions stay with the wallet service
NIP-47 Nostr Wallet Connect defines a way for an app to request wallet actions through encrypted Nostr events over relays. Nodana is not the standard and not the app asking to spend. In a Nodana-hosted Alby Hub setup, Alby Hub is the wallet service that creates and honors NWC connections.
That distinction affects security reviews. The NWC URI, relay choice, wallet service public key, client secret, budget, allowed methods and revocation flow belong to the wallet service. Nodana's role is to keep that service reachable, isolated, backed up and updated.
If a Nostr client such as Damus, Amethyst, noStrudel or another app connects to your hosted Hub, the wallet permission design still matters. Use narrow budgets, named connections, expirations where available and a habit of revoking unused app connections. A cloud-hosted wallet service should not become a permanent open tab into your funds.
The clean mental model is: Nodana hosts. Alby Hub authorizes. Nostr relays transport encrypted wallet requests. The connected app asks. The Lightning backend pays or receives. When debugging, identify which layer is failing before changing settings.
What to test before funding
Start with a tiny deployment. Create a Nodana account with the login method you intend to keep, deploy Alby Hub or Alby Hub with Phoenixd, open the generated URL, complete initial setup and record the recovery information before adding meaningful funds.
Then test payments. Deposit a tiny amount, create a small invoice, pay a small invoice, restart or wait for the service to settle, and confirm the hosted app remains reachable. If Phoenixd is the backend, check the Phoenixd documentation and fees so you know what automated liquidity means in practice.
Next test NWC. Create a dedicated low-budget connection in Alby Hub. Connect one app. Pay a tiny invoice. Revoke the connection. Confirm the app cannot keep spending. If the revoke path is confusing, solve that before connecting a larger wallet or more apps.
Finally test account operations. Check notifications, billing, balance top-up, support path, update prompts and backup expectations. A hosted node is only as comfortable as your ability to manage it on an ordinary stressful day.
Who should consider Nodana
Nodana is a sensible option for users who want to experiment with Bitcoin and Lightning apps quickly, especially when they do not want to run a home server or manage a VPS. It is also useful for developers who need public test endpoints for Alby Hub, LNbits, Phoenixd, Cashu or Boltz-related work.
It is less suitable for someone who wants complete physical control over hardware, wants to avoid all hosted dependencies, needs custom network architecture, or must satisfy strict institutional security requirements. A cloud-hosted app can be private enough for some uses and too hosted for others.
For a creator or small community, Nodana can be a bridge. Run Alby Hub in the cloud, connect apps through NWC, test Lightning payments, and learn the operational shape before deciding whether to move to Start9, Umbrel, RaspiBlitz, Unraid, CasaOS or a self-managed server.
For production funds, choose slowly. Compare Nodana's convenience with self-hosting, Alby Cloud, Start9, Umbrel and plain VPS deployments. The right answer depends on who controls access, who restores backups, who pays the bill and how much value the service can move.
The bottom line
Nodana makes the NWC world easier to enter because it gives Bitcoin and Lightning apps a hosted home. You can deploy Alby Hub, Alby Hub with Phoenixd, LNbits, Phoenixd and other tools without building the server stack yourself.
That convenience should be described honestly. Nodana is not the wallet, not the NWC protocol and not a guarantee that every hosted template is safe for production money. It is the platform where wallet and payment services can run.
Use it with tiny first steps. Deploy, test, document, back up, update, revoke, restore and only then decide whether the hosted service deserves more responsibility. The biggest mistake would be treating a one-click deployment like a one-click security model.
If you keep the layers separate, Nodana is valuable. It can turn a hard infrastructure afternoon into a short test. The remaining work is the part that matters most: knowing which service holds funds, which app has permission, which backup restores state and which operator can fix the stack when payments stop.
Sources worth opening
Open Nodana's home page, FAQ, security page, introduction post and the template pages first. Then compare the Alby Hub, Phoenixd, LNbits, Cashu, Boltz and NIP-47 sources so you know which layer is hosting, which layer is wallet logic and which layer is payment authority.
- Nodana home page
- Nodana introduction post
- Nodana FAQ
- Nodana security page
- Nodana terms
- Nodana privacy policy
- Nodana GitHub organization
- Nodana CLI repository
- Nodana API reference repository
- Nodana Alby Hub template
- Nodana Alby Hub and Phoenixd template
- Nodana Phoenixd template
- Nodana LNbits template
- Nodana LNbits and Phoenixd template
- Nodana CDK Mintd template
- Nodana Nutshell template
- Nodana Boltz Client template
- Nodana Fedimintd template
- Nodana Gatewayd template
- getAlby awesome-nwc list
- awesome-nwc raw README
- Alby Hub official site
- Alby Hub GitHub repository
- Alby Hub raw README
- Alby Hub node guide
- Alby app connections via NWC
- Nostr Wallet Connect site
- Nostr Wallet Connect docs
- NIP-47 Nostr Wallet Connect
- Phoenix official site
- Phoenixd GitHub repository
- Phoenixd raw README
- LNbits official site
- LNbits GitHub repository
- LNbits raw README
- Cashu official site
- Cashu NUT specifications
- Cashu CDK repository
- Cashu Nutshell repository
- Boltz official site
- Boltz Client repository
- WebLN specification
