Community

Apps

RaspiBlitz

RaspiBlitz is for the reader who wants a real home Bitcoin and Lightning node, not just a cloud wallet. In the Nostr map it matters because a node like this can host the wallet service that answers NWC requests.

RaspiBlitz visual
RaspiBlitz icon
Apps The product layer Clients, signers, publishing tools, wallets and useful experiments.
Back to Nostr
Apps

Apps shelf

Apps pages collect clients, signers, tools, developer libraries and product research without turning the app into the whole network.

Apps31 min readDIY Bitcoin and Lightning node operating system for running self-hosted NWC-capable wallet infrastructure

RaspiBlitz

RaspiBlitz is for the reader who wants a real home Bitcoin and Lightning node, not just a cloud wallet. In the Nostr map it matters because a node like this can host the wallet service that answers NWC requests.

The quick readRaspiBlitz is not a Nostr social app and not Nostr Wallet Connect by itself. It is a long-running open-source project for building a Bitcoin full node and Lightning node on Raspberry Pi 4 or 5 hardware, with optional display, SSH menus, WebUI setup, app installs and recovery tooling. The current public release checked on June 13, 2026 was v1.12.1, published on March 3, 2026, with a major v1.12 storage-layout warning: once you move into the v1.12.x layout, downgrading below v1.12 is not supported. For Nostr users the important connection is indirect but real. The `getAlby/awesome-nwc` list places RaspiBlitz under embedded operating systems because it can support at least one NWC wallet through its official app ecosystem. In practice, that means Alby Hub on RaspiBlitz, backed by the node's LND service in the RaspiBlitz integration script, or other NWC paths that use LND, CLN, LNbits or wallet services running on the box. Treat RaspiBlitz as a home-node operating surface: check hardware, image hashes, release notes, backup state, channel risk, macaroon exposure, Tor or clearnet reachability, app versions and NWC permissions before you put meaningful funds behind it.

RaspiBlitz is a node system

RaspiBlitz is best understood as a home Bitcoin and Lightning node system with a strong learning culture around it. The official documentation calls it a DIY Bitcoin and Lightning node for Raspberry Pi, and the GitHub README describes a full node on Raspberry Pi 4 and 5 hardware with an optional display for setup and monitoring. That framing matters because the Nostr map can make RaspiBlitz look like a wallet product. It is broader and more operational than that.

If you are reading from the Nostr side, the most useful mental model is this: RaspiBlitz is the machine and operating stack that can run the wallet service. It is not the app that zaps from your timeline. It is not a browser signer. It is not a NIP-47 protocol implementation by itself. It runs Bitcoin Core, LND or Core Lightning, app services, web interfaces, Tor plumbing, backups and management scripts so other tools can safely talk to your node.

That distinction keeps expectations honest. A Nostr app wants a wallet connection string, a relay path and permissions. RaspiBlitz gives you a place to host the wallet backend that can honor those requests. If the hosted service is Alby Hub, then Alby Hub handles the Nostr Wallet Connect flow. If the service is LNbits with an NWC extension, the extension and LNbits account model matter. If the path is CLN with a NWC plugin, the CLN plugin decides the contract. RaspiBlitz is the base.

The project has also been around long enough that it carries a different weight from a new landing page. It has release branches, detailed docs, a large issue history, community support channels, workshop material and many small scripts that expose how the system is actually assembled. That is valuable for a reader who wants to verify, not just click. It also means you inherit real node-operator responsibilities: uptime, backups, updates, storage health and hot-wallet risk.

The current release context

The current public release checked for this article was RaspiBlitz v1.12.1, published on GitHub on March 3, 2026. The GitHub API showed the repository under the `raspiblitz/raspiblitz` organization, MIT licensed, with the `dev` branch as default, more than 2,500 stars, more than 550 forks and hundreds of open issues. Those numbers are not a quality guarantee, but they confirm that this is an active, visible open-source project rather than an abandoned node image.

Version 1.12.1 is not just a small app bump. The release notes describe updated apps, fixes and optimized migration to larger SSD or NVMe drives. The linked change log lists Bitcoin Core v29.2, Core Lightning v25.12.1, electrs v0.10.10, Alby Hub v1.20.0, Specter Desktop v2.1.1, Fulcrum v2.1.0, optional Bitcoin Knots 29.2 and several other application updates. That matters because a RaspiBlitz node is a bundle of many upstream systems.

The bigger line is the v1.12 storage layout. The download docs and release notes both warn that once a node is updated into the v1.12.x data layout, you cannot revert to a version older than v1.12 because the SSD or NVMe layout changes. A casual app review might skip this. A serious node page cannot. If your node has channels, app databases, Tor keys, certificates and wallet state, a storage layout migration is an operational event, not a visual refresh.

This is also why release timing matters. A Nostr user looking for a stable NWC backend may be tempted to install the newest image because the app they want is newer there. That can be right, but read the release notes first. If you are upgrading from a pre-v1.12 system, export or verify the correct backups, understand the migration path, and test with small balances before treating the box as the always-on wallet behind your Nostr apps.

Hardware shapes the experience

RaspiBlitz still has Raspberry Pi in its name for a reason. The hardware page says it runs on Raspberry Pi 4 and 5 and strongly recommends a Raspberry Pi 5 with 8 GB RAM for new builds. The current setup guidance points toward a 2 TB NVMe drive and notes that the display is optional but helpful for setup and monitoring. The move toward NVMe is not cosmetic. Initial block download, chain validation and app workloads punish weak storage.

Raspberry Pi nodes have a charm that is easy to underestimate. They are small, quiet, affordable and visible. You can place the box on a shelf and know that your wallet backend is in your home. That is powerful for learning and self-custody. It is also a reminder that you are not renting a managed platform. Power supply quality, cooling, storage health, local network reliability and physical access all become part of the payment system.

The older SD-card-only mental picture is increasingly wrong for a serious node. RaspiBlitz v1.12.0 introduced boot-from-NVMe on Raspberry Pi 5, copy from old HDD, SSD or NVMe drives and optional separation of data and storage or blockchain drives. Those choices exist because storage is where node projects live or die. A flaky SD card may boot a dashboard. It should not be the foundation for a Lightning node with channels and wallet state.

If you are choosing between RaspiBlitz, Umbrel, Start9, CasaOS, Unraid or a plain Linux server, hardware is part of the decision. RaspiBlitz is comfortable when you want a Bitcoin-first appliance you can build and inspect. It is less attractive if you want a general NAS, media server or app dashboard first. For NWC work, the question is not which box looks friendliest. It is which box you can keep powered, cooled, backed up and updated.

Setup is a weekend, not a click

The docs present ready-to-use SD card images. As of the v1.12.1 download page, there are two main paths: the fatpack image for beginners and WebUI-friendly app setup, and the minimal image for experienced users who want fewer preinstalled features and a smaller attack surface. The fatpack is easier. The minimal image is quieter and more deliberate. Neither turns a Lightning node into a risk-free consumer app.

A fresh setup asks you what to do with the attached drive, whether existing blockchain data should be kept, and whether you are starting new or importing from backup. You then name the node, and that name becomes the public alias of the Lightning node. You also choose the Lightning implementation: LND, Core Lightning, both later, or no Lightning if you only want a Bitcoin full node. This first choice determines which services and app connections are available.

Initial blockchain sync is the big time cost. The final setup docs explain that you can self-sync or copy a validated blockchain from another computer or another RaspiBlitz on the local network. The copy path can save time, but it still asks you to trust your own validation process. The docs use the old Bitcoin maxim in practice: if you can validate the chain yourself, do not blindly trust a downloaded shortcut.

For the Nostr reader, this means RaspiBlitz is not a quick way to get zaps working this afternoon unless you already have the node prepared. If your immediate need is a wallet connection for one client, Alby Cloud, an existing Alby Hub, Zeus, Mutiny-style wallets or other NWC wallets may be faster. RaspiBlitz fits when your goal is to operate the backend yourself and you are willing to learn the node lifecycle.

LND and Core Lightning are the core

RaspiBlitz started in the LND world, and the docs still describe LND as the implementation used by most Raspberry Pi Lightning node projects and compatible with many additional apps. The setup also supports Core Lightning for more experienced operators and developers who want its plugin model. The docs say you can later run both implementations in parallel, though the first setup asks you to pick one to start with.

This matters for Nostr Wallet Connect because NWC is not one monolithic wallet. It is a way for an app to ask a wallet service for wallet actions over Nostr relays. The service behind that NWC connection may use LND, CLN, Phoenixd, LDK, Cashu, LNbits, Alby Hub or another backend. RaspiBlitz gives you serious backends, but the specific NWC behavior depends on the bridge you install and the backend it talks to.

LND brings macaroons, TLS certificates, channel backup files, `lncli`, REST or gRPC integrations and a large wallet app ecosystem. CLN brings a different architecture, plugin culture, runes in newer tooling and a strong developer audience. RaspiBlitz exposes both through menus and service scripts, but it cannot make their risk models identical. A permissioned CLN plugin and an LND admin macaroon are not the same object.

If you are setting up a RaspiBlitz for Nostr payments, decide which backend will actually move money. Then trace the path: Nostr app, NWC relay, wallet service, backend API, Lightning channel, peer, on-chain fallback. Write down where each credential lives. That one map will help you debug failed zaps, stuck invoices, permission mistakes and backup gaps much faster than remembering that the box is called RaspiBlitz.

Alby Hub is the practical NWC bridge

The strongest current RaspiBlitz link to Nostr Wallet Connect is Alby Hub. The RaspiBlitz intro page lists Alby Hub as a WebUI-installable service, described as a feature-rich Lightning wallet connector. The RaspiBlitz v1.12.1 change log updates Alby Hub to v1.20.0. The actual RaspiBlitz integration script, `bonus.albyhub.sh`, defines Alby Hub version 1.20.0, creates a systemd service, sets ports, prepares a data directory and configures it to use LND as the backend.

That script is the kind of source worth reading because it shows the operational truth. It sets `LN_BACKEND_TYPE=LND`, points to `127.0.0.1:10009`, uses the LND TLS certificate and admin macaroon paths under app data, creates an `albyhub` service user, places it in the `lndadmin` group, opens firewall ports, writes nginx configuration and optionally sets up a Tor hidden service. This is not just a button in a store. It is a service with real credentials.

Alby Hub itself describes the product as a wallet hub that lets applications supporting NWC connect to your Lightning node or wallet. It can run as a desktop app or an HTTP web app, and it supports an embedded LDK node by default plus external backends such as LND, Phoenixd, Cashu and CLN. On RaspiBlitz, the packaged route is specifically an always-on Alby Hub service backed by the RaspiBlitz LND node.

That gives RaspiBlitz a credible place in the Nostr ecosystem. A Nostr client such as Damus, Amethyst, noStrudel or another app does not need to control your node directly. It can receive a scoped NWC connection from Alby Hub. The safer setup is per-app connections with permissions, budgets and expiry. The dangerous setup is treating an NWC URL like a bookmark and pasting it everywhere. RaspiBlitz makes self-hosting possible; Alby Hub makes the NWC boundary usable.

What awesome-nwc is really saying

The `getAlby/awesome-nwc` list is the direct source for why RaspiBlitz belongs on the Nostr apps map. Its embedded operating systems section says CasaOS, RaspiBlitz, Start9, Umbrel and Unraid support at least one NWC wallet in their official app stores. For RaspiBlitz, that is not a claim that the operating system emits NIP-47 requests. It is a claim that the system can host NWC-capable wallet software through the supported app path.

The same list also separates NWC wallets, embedded operating systems, cloud hosting of NWC nodes, Lightning backends and wallet services. That structure is useful because it prevents category confusion. Alby Hub is a NWC wallet service. LND and CLN can be Lightning backends. RaspiBlitz is an embedded operating system. A social client is an app consuming the connection. Each piece has a different security boundary.

For a reader, the important takeaway is simple: RaspiBlitz gives you infrastructure that can make NWC self-hosted. It does not remove the need to inspect the wallet service. If Alby Hub is installed, read Alby Hub docs and release notes. If LNbits is installed, inspect LNbits version, funding source and extension behavior. If a CLN NWC plugin is used, read that plugin. If a Nostr app asks for broad permissions, create a narrower connection.

This is the same discipline that makes self-hosting worth doing. A map entry is a starting point, not a warranty. RaspiBlitz is in the NWC world because it can be a home for the service that signs wallet actions. It should be evaluated at that layer: does the node stay online, can you revoke connections, can you restore state, and can you explain which process is allowed to spend?

Services make the node useful

RaspiBlitz is not only a Bitcoin Core and Lightning installer. The intro and SSH menu docs list a wide app surface: Ride the Lightning for LND and CLN management, ThunderHub for LND, BTC-RPC-Explorer, BTCPay Server, LNbits, Mempool, JAM, Alby Hub, electrs, Fulcrum, Specter Desktop, Lightning Terminal, JoinMarket, Balance of Satoshis, Circuit Breaker, Telegraf metrics, chantools, Suez and more. Some are WebUI-friendly, while others live in the SSH menus.

That app surface is why RaspiBlitz can become more than a hobby node. You can connect mobile wallets, run an Electrum server for wallet privacy, host BTCPay Server, use LNbits accounts or extensions, inspect mempool data, manage channels in RTL, visualize liquidity and expose selected services through Tor or HTTPS. For Nostr payments, these services can become the practical support layer around a NWC wallet.

The flip side is attack surface. The security policy explicitly says the fatpack image improves beginner experience by preinstalling and activating many features, including LCD, API, WebUI and a selection of additional apps, but that this creates a bigger attack surface and more trusted dependencies. Advanced users are pointed toward the minimal image when they know what they need. That is unusually honest and worth taking seriously.

If you want RaspiBlitz only to host Alby Hub for NWC, do not enable every service because the menu is interesting. Install the smallest useful set, keep app ports private unless they need to be public, and document why each service is there. A self-hosted node can become safer than a custodial wallet only when its operator resists the urge to turn it into a public dashboard for everything.

Credentials are the sharp edge

RaspiBlitz exposes several credential paths because node operators need to connect wallets and apps. The SSH menu docs describe exporting LND macaroons and TLS certificates for app access. They also explain that macaroons are access tokens allowing certain command execution on the LND node, while TLS certificates secure communication. That language should ring loudly for any Nostr user who is about to connect wallet software.

The docs warn that browser download of macaroons and TLS files is the least secure transfer method because everyone on the local network can access the files during the download window, and an admin macaroon can allow someone to take over the node and spend funds. That warning is practical, not theoretical. If you expose an admin macaroon to a service that does not need it, you have blurred the boundary between app convenience and node custody.

NWC helps by moving app permissions into a wallet-service layer. A Nostr app should not need your LND admin macaroon. It should get a NWC connection with only the methods it needs. The NWC best-practice docs emphasize configurable permissions, budgets, unique wallet keys for each connection and sub-wallet isolation. RaspiBlitz can host the backend, but the wallet service must still be configured with the least authority that works.

A good RaspiBlitz NWC setup therefore has at least three levels of credentials. The node backend has powerful LND or CLN credentials. The wallet service has backend credentials and its own login. Each Nostr app receives a separate NWC connection. Never collapse those layers for convenience. If you cannot revoke one app without touching the whole node, the setup is not yet clean enough for regular use.

Backups are not optional

Lightning backups are more subtle than file backups. The RaspiBlitz setup docs describe migration files, LND or Core Lightning rescue files, seed plus static channel backup recovery and seed-only fallback. The FAQ is direct: the best chance to recover LND data and channels is when you can still SSH into the RaspiBlitz and the disk is reachable. It also warns that an outdated channel backup can risk channel funds.

The basic setup page says a migration file can include LND data, Bitcoin wallet information, `raspiblitz.config`, Tor and SSH keys and installed apps. That is useful when moving to new hardware. It is also a reminder that backup scope differs by purpose. A migration file, an LND rescue file, a seed phrase, a static channel backup, an app database backup and an exported NWC connection list are not interchangeable.

The security policy says there is no perfect backup concept for funds in Lightning channels and recommends using LND Static Channel Backup while keeping it offline. It also notes that the Bitcoin Core wallet is deactivated by default and, if activated by apps, is not backed up by the RaspiBlitz setup seed. That small line matters. A reader who uses JoinMarket, Fully Noded or other tools may hold funds outside the default Lightning wallet model.

Before you run Nostr payments from RaspiBlitz, perform a backup rehearsal. Find the Alby Hub data directory, the LND or CLN state, the static channel backup, the seed material, Tor keys, certificates, app databases and any LNbits or BTCPay state. Write down which backup recovers which loss. Then test with tiny balances. The first restore attempt should not happen after a drive dies.

Network exposure changes the threat model

A RaspiBlitz node can be local, reachable through Tor, reachable through a tunnel, or exposed through HTTPS for selected services. The SSH menu docs describe IP2Tor, HTTPS with LetsEncrypt, nginx configurations, Tor hidden services and service-specific connection screens. Those features are useful because a node operator may want mobile access, payment processing, wallet connectivity or public service endpoints without opening a router carelessly.

NWC can reduce the need to expose a wallet web UI. A client can send encrypted requests through Nostr relays to the wallet service, and the service can answer without the client holding node credentials. That is a good design. It does not mean the underlying host can be neglected. If the Alby Hub admin interface, RaspiBlitz WebUI, LNbits admin panel or LND credentials are exposed poorly, NWC encryption will not save you from host compromise.

RaspiBlitz has some hardening defaults. The security policy says Wi-Fi and Bluetooth are disabled by default in the build script, UFW is active with only specific ports open, and Fail2Ban protects SSH from brute-force attacks. It also says the `admin` user has passwordless sudo access to support installations and reading passwords with less user friction. That is a pragmatic tradeoff, and it belongs in the threat model.

The safe pattern is private administration and deliberate public services. Use LAN, SSH, Tor or a VPN-style path for admin surfaces. Put only the user-facing service behind public HTTPS or Tor, and only when you understand the ports, certificates and authentication. If a Nostr client can reach your wallet through NWC, it usually does not need your node dashboard to be open to the world.

Updates need operator judgment

RaspiBlitz does not present itself as a silent auto-update appliance. The SSH menu docs say it does not support automatic over-the-air updates, intentionally, to avoid remote control of your node from a central server. Updates happen through release preparation, patching, optional interim updates for LND or Bitcoin Core and app-specific paths. That design is slower, but it respects the fact that a Lightning node is money infrastructure.

The v1.12.1 release shows why operator judgment matters. It updates multiple upstream applications at once and includes a migration optimization tied to storage layout changes. A one-click platform might hide that complexity. RaspiBlitz makes much of it visible through change logs and menu steps. You still need to decide when to move, how to back up, whether an app version is worth the risk and whether a channel-heavy node should wait for community reports.

The Alby Hub script also illustrates app-update coupling. In v1.12 it packages Alby Hub v1.20.0. If Alby Hub upstream releases a newer security fix or NWC feature, RaspiBlitz users may need to wait for a RaspiBlitz update, patch manually, or use a future app-specific update path. There is even issue discussion around adding a direct Alby Hub update option. That is normal self-hosting friction, not a reason to panic.

For NWC use, update policy should match spending authority. A receive-only connection can tolerate more experimentation than a connection allowed to pay invoices. A node with tiny channels can test faster than a node routing significant liquidity. Read release notes for RaspiBlitz, Alby Hub, LND or CLN and the Nostr app consuming the connection. Then update in a window where you can watch logs and test payments.

Privacy is layered

Running your own node improves some privacy because your wallet does not need to ask random public Electrum servers or hosted Lightning providers for everything. RaspiBlitz can run electrs or Fulcrum, connect wallets to your own server, run Tor services and keep node data on hardware you control. That is a meaningful privacy gain for users willing to operate it well.

It is not automatic invisibility. Your node alias, channel graph behavior, public Lightning channels, Tor usage, Nostr relay choices, wallet service logs and app permissions can all leak different metadata. A NWC relay may not hold your funds, but it can observe timing and routing metadata. A wallet service can see what an app asks for. A Nostr app with balance or transaction permissions can learn more than a zap button needs.

The RaspiBlitz security page also notes that debug logs are filtered for private data such as node IDs, IP addresses, onion addresses and balances, but users should still check before sharing publicly. That is good advice beyond debug logs. Screenshots of QR codes, connection strings, macaroon export dialogs, channel lists or app settings can reveal operational details that an attacker would love to have.

Use RaspiBlitz to improve privacy where it is strong: own chain validation, own Electrum server, Tor reachability, self-hosted wallet services and scoped app connections. Do not expect it to hide all payment metadata from counterparties, Nostr relays, wallet services or public Lightning graph observers. Privacy comes from a stack of deliberate choices, not from the presence of a small node on your desk.

How to test NWC on RaspiBlitz

Start with the node before starting with Nostr. Confirm that RaspiBlitz is on the release you intend to run, that the image hash and signature were checked, that the hardware is stable, that the blockchain is fully synced, that LND or CLN is healthy and that you can safely restart the machine. Then open and close a tiny Lightning channel or use a tiny test payment path appropriate to your backend.

If you use Alby Hub, install it through the RaspiBlitz service path, open it locally first, set a strong separate Alby Hub password and confirm which backend it is using. On the RaspiBlitz packaged path, expect LND. Verify that the hub starts after reboot, that logs are understandable, that the data directory is included in backup planning and that the Alby Hub version matches what the RaspiBlitz release says.

Then create one NWC connection for one app. Give it a clear label, a small budget, a short expiry and only the methods the app needs. A social client that zaps usually does not need broad administrative access. Test a small invoice, a small payment, a failed payment, a reboot and a revocation. Confirm that the Nostr app stops working after revocation. That is the practical proof that the boundary is real.

Finally, test the network path you will actually use. If your phone will zap while away from home, test mobile data. If the service uses Tor, test Tor. If it relies on one NWC relay, test what happens when that relay is down or blocked. If an app asks you to paste a fresh connection later, do not reuse the old one casually. Treat every NWC URL like a limited spending key.

Where RaspiBlitz fits beside the others

RaspiBlitz sits in the same broad embedded operating systems group as CasaOS, Start9, Umbrel and Unraid, but its center of gravity is different. CasaOS is a general personal cloud and Docker dashboard. Umbrel is a polished home-server app experience with a strong Bitcoin audience. Start9 is a personal-server operating system with service packaging and marketplace assumptions. Unraid is a storage and NAS operating system with a large container ecosystem.

RaspiBlitz is the most explicitly workshop-like Bitcoin and Lightning node project in that group. It expects the operator to learn. The optional display, SSH menu, WebUI, documentation, recovery pages and community support all point toward hands-on node ownership. That is exactly why it can be a good NWC base for a reader who wants to understand what is behind the wallet connection.

The tradeoff is polish and scope. If you want one box to be family media, photo backups, home automation, file sync and a casual wallet service, a more general server OS may feel easier. If you want a Bitcoin node first, with LND or CLN, channel tools, BTCPay Server, LNbits, Alby Hub, Electrum services and clear backup rituals, RaspiBlitz has the right shape.

For Nostr users, the choice should follow custody appetite. If you only want a cheap way to zap, a hosted wallet may be fine. If you want to connect apps to funds you control and can maintain, RaspiBlitz deserves a close look. It is not the easiest path, but it is one of the more inspectable ways to make the wallet behind Nostr payments belong to you.

Who should use it

RaspiBlitz fits the reader who wants to learn by running the machinery. You should be comfortable with SSH, release notes, storage devices, backups, passwords, QR codes, Lightning channels and the idea that a node can be temporarily offline. You do not need to be a protocol developer, but you do need patience. The docs even frame setup as a weekend project in workshop contexts because chain sync and hardware preparation take time.

It also fits builders who want a local backend for experiments. A developer testing NWC flows, LNbits apps, BTCPay setups, CLN plugins, LND tools or mobile wallet connections can learn a lot from a RaspiBlitz box. The scripts are visible, the service model is concrete and the support ecosystem has years of discussions. That is better than treating a remote API as magic.

It is less ideal for someone who wants zero-maintenance zaps, instant onboarding or a wallet that feels like a normal app subscription. Running RaspiBlitz means accepting hot-wallet risk, update windows, hardware failure, channel management and the possibility that an app integration breaks after an upstream release. That does not make it bad. It makes it honest infrastructure.

If you proceed, start small. Use the latest docs, verify downloads, prefer the hardware path the project currently recommends, keep balances modest until recovery is tested and create narrow NWC connections per app. RaspiBlitz can be a strong home for your Nostr payment backend when you respect it as a node, not as a decorative icon in an app directory.

The reader takeaway

RaspiBlitz matters to the Nostr ecosystem because it gives a technically curious user a path to run the backend behind permissioned Nostr payments. It is not a social client, not a relay and not a NIP-47 service on its own. It is the operating surface that can run LND, CLN, Alby Hub, LNbits, BTCPay Server, Electrum services, Tor routes and the backup scripts that make a self-hosted payment stack viable.

The current v1.12 generation is especially worth reading carefully because it changed the storage layout and moved deeper into Raspberry Pi 5 plus NVMe assumptions. That makes the project more serious for modern node workloads, but it also raises the cost of casual upgrading. A node that can host your NWC wallet is a living system. It deserves release-note habits, backup habits and a small test budget.

The best RaspiBlitz setup for Nostr is boring in the right way. It is powered reliably, cooled properly, synced, backed up, updated intentionally and reachable only through deliberate paths. Alby Hub or another wallet service issues one connection per app. Each connection has a budget, permissions and a way to revoke it. The Nostr app never sees raw node credentials.

If that sounds like the experience you want, RaspiBlitz is one of the clearest ways to make Nostr payments feel anchored in your own infrastructure. If it sounds like too much work, that is useful information too. Nostr Wallet Connect lets many wallet types participate. RaspiBlitz is the path for readers who want the node, the learning curve and the responsibility together.

Sources worth opening

Start with the RaspiBlitz docs, GitHub repository, current release notes, security policy and setup pages. Then read the Alby Hub integration, NWC specification material and the backup or recovery documentation before using a RaspiBlitz-hosted service for Nostr payments.

Back to the Crays Nostr page
Apps route visual cue 1
Apps route visual cue 2
Apps route visual cue 3
Apps route visual cue 4
Apps route visual cue 5

How to use this page

Keep the product map close.

Search the wider app shelf when you want another client, tool, protocol reference or source trail beside this page.

AppsMore Apps pages stay availableApps pages stay availableProducts, tools, communities and source trails.Browse pages
Apps contribution visual cue 1
Apps contribution visual cue 2
Apps contribution visual cue 3
Apps contribution visual cue 4
Apps contribution visual cue 5

Bring something back

Ask, suggest, submit or nominate.

Ask a question, send a source, suggest a fix, submit a project or nominate a public Nostr account. The page stays stable; your contribution gets reviewed beside it.