CasaOS
CasaOS is a personal cloud layer for home servers. It gives you a friendly dashboard, app store, file tools and Docker-based application management, so the Nostr question is what you can safely host on top of it.
CasaOS is a home-server layer
CasaOS is best understood as a personal cloud layer for a machine you control. The official site describes it as community-based open-source software focused on a simple personal cloud experience around the Docker ecosystem. It gives you a browser dashboard, an app store, storage views, file sharing and a way to install self-hosted applications without living inside a terminal all day.
That framing matters because the name can make people expect a full operating system in the traditional sense. CasaOS normally runs on top of an existing Linux installation or on hardware from the IceWhale/ZimaSpace world. It is a web-managed home-server environment and application layer, not a new kernel or a Nostr-specific distribution.
For a Nostr reader, the important point is even narrower. CasaOS does not make your server a Nostr relay, a Lightning node or a wallet. It gives you a place where those services may be installed, configured, updated, exposed and backed up. If you use Nostr Wallet Connect from a service hosted there, CasaOS is part of the operational surface.
That is why CasaOS deserves a careful page instead of a generic mention. A self-hosting dashboard can be the difference between a wallet service you actually maintain and a forgotten Docker container with secrets in plain sight. The product is approachable, but payment infrastructure rewards precise habits.
The IceWhale and ZimaSpace context
CasaOS comes from the IceWhale/ZimaSpace ecosystem, the same orbit as ZimaBoard, ZimaBlade, ZimaCube and ZimaOS. The CasaOS GitHub repository is owned by IceWhaleTech, uses the Apache-2.0 license and describes the project as a simple, easy-to-use, elegant open-source personal cloud system.
The official site now places CasaOS in a transition story. It says the team has upgraded CasaOS to ZimaOS and points visitors toward the next-generation NAS operating system. That does not erase CasaOS, but it changes how you should evaluate new deployments. You are looking at a mature open-source project that is also being superseded by a related product line.
GitHub metadata checked on June 13, 2026 showed the CasaOS repository with more than 34,000 stars, more than 1,900 forks, hundreds of open issues, a default branch named `main` and a latest stable release line around v0.4.x. The scale is real. So is the maintenance question.
If you are setting up a fresh server in 2026, compare CasaOS and ZimaOS before you put valuable services on the box. If you already run CasaOS, read the migration documentation before moving containers, files or databases. The safest choice is the one whose update path you understand before anything breaks.
What the dashboard actually gives you
The CasaOS pitch is deliberately practical. It promises a friendly UI for home scenarios, one-click app installation, Docker ecosystem compatibility, drive and file management, system widgets and support for hardware ranging from Raspberry Pi boards to NUCs, ZimaBoard devices and older computers that can run a supported Linux base.
The dashboard is the front door. You can see installed applications, open them, manage storage, browse files and add software from a store rather than hand-writing every compose file. That lowers the barrier for people who want Jellyfin, Nextcloud, Home Assistant, AdGuard, Immich, Pi-hole, media stacks or other self-hosted tools without building a platform from scratch.
For Nostr and Lightning work, the dashboard is convenient because many wallet-adjacent tools are web services. A Lightning backend, NWC wallet service, relay, indexer, database, reverse proxy and monitoring tool all want ports, volumes, environment variables and updates. CasaOS gives those pieces a visible home.
Convenience is not the same as abstraction away from risk. Docker applications still mount volumes, expose ports, pull images and keep state on disk. If a hosted wallet service stores a macaroon, API key, seed material, NWC connection secret or database under CasaOS-managed volumes, the dashboard becomes part of your payment security model.
The Docker app-store model
CasaOS is built around Docker applications and app-store manifests. The official CasaOS-AppStore repository contains manifest files for apps. The CasaOS site says the software can install preconfigured Docker-based applications and also reach into the much larger Docker ecosystem when you bring your own compose setup.
This is the feature that makes CasaOS appealing. You do not need to remember every container command to try a service. You can install from a curated store, add third-party stores or import an external Docker Compose file. For home servers, that can turn a weekend of setup into an afternoon of controlled experimentation.
The same model creates a trust chain. You are trusting the app-store repository, the manifest author, the Docker image publisher, the image tag, the volume mapping, the port mapping, the update mechanism and any secrets you enter. For a photo library this is already important. For Nostr Wallet Connect, it is critical.
Before installing an NWC-capable wallet service through CasaOS, open the compose or manifest. Check which image is used, whether the tag is pinned, which directories are mounted, whether environment variables hold secrets, which ports are exposed and whether the service expects HTTPS or a trusted reverse proxy in front of it.
Why it appears in the NWC world
The direct Nostr Wallet Connect source to care about is `getAlby/awesome-nwc`. Its embedded operating systems section lists CasaOS together with RaspiBlitz, Start9, Umbrel and Unraid, and says those systems support at least one NWC wallet in their official app stores. That is the actual bridge into the NWC map.
This does not mean CasaOS speaks NIP-47. NIP-47 describes a wallet service and app communicating through encrypted Nostr events over a relay. CasaOS is the server surface that may host the wallet service. The wallet or backend does the NWC work; CasaOS starts it, stores it, updates it and exposes it.
That distinction protects you from a common mistake. If a map places CasaOS near Nostr Wallet Connect, it is tempting to treat it as a wallet. It is not. It is closer to the shelf, workbench and breaker panel for your wallet services. The tools on the shelf still need their own review.
A good CasaOS setup for NWC might host Alby Hub, LNbits or another payment service, plus a reverse proxy, backups and monitoring. A weak setup might install something once, expose it to the internet, never update it and store connection secrets in places nobody audits. The same dashboard can support either outcome.
NIP-47 still belongs to the wallet service
NIP-47 defines the contract between a Nostr app and a remote Lightning wallet service. The app gets a `nostr+walletconnect://` connection, sends encrypted requests through a relay and asks for actions such as paying an invoice, making an invoice, reading balance or listing transactions depending on the wallet's supported methods.
CasaOS does not change that contract. If the wallet service is Alby Hub, CLN with an NWC bridge, LNbits with relevant extensions, phoenixd behind an NWC layer or another implementation, that service decides the supported commands, budgets, permissions, keys, relays and accounting semantics.
When you run the service on CasaOS, you add a hosting question: is the service always on, reachable, updated and backed up? NWC is useful because apps can request wallet actions without a manual QR scan every time. That usefulness depends on the server process being alive and on the connection secret being handled with care.
So the reader's question should be concrete: which wallet service is installed, where is its state, which NWC permissions did you grant, which relay does it use, what spending limit exists, how do you revoke it and what happens if the CasaOS machine reboots while a payment request is in flight?
Alby Hub and LNbits are the likely comparison points
CasaOS is not a Lightning backend, so it should be compared with other hosting surfaces rather than with Alby Hub or LNbits directly. Alby Hub is a wallet and node-management application designed around Nostr Wallet Connect. LNbits is an account and extension layer for Lightning services. CasaOS is the environment where applications like those may run.
That layering can be good. You might want a plain home-server dashboard to host a wallet service, a media library, a file sync tool and a monitoring stack on the same box. CasaOS can make that approachable for a non-specialist operator who still wants self-hosted control.
It can also hide boundaries if you are not careful. If Alby Hub holds the wallet state and CasaOS holds the Docker volume, then your backup plan must include that volume. If LNbits uses a backend wallet and database, your CasaOS snapshot must not miss the database. If an NWC secret is shown once, you need to know where you stored it.
Treat each layer separately. CasaOS hosts. Docker runs. The wallet service speaks NWC. The relay transports encrypted Nostr events. The Lightning backend moves sats. The browser dashboard opens controls. When something fails, that mental map helps you find the right place to look.
Installing is easy; operating is the work
The CasaOS site still advertises a one-command installation using `curl -fsSL https://get.casaos.io | sudo bash`. That is a familiar pattern in self-hosting, and it can be perfectly convenient on a test box. It is also a command that asks you to trust a remote installer with root privileges.
For anything payment-related, read installation instructions, supported distributions and issue history first. CasaOS issue threads include reports about distro detection, Ubuntu installation failures, app store loading problems, Docker version mismatches and storage display bugs. Not every report affects every user, but they show where operators have hit friction.
After installation, operating discipline matters more than the first success screen. Update the base OS, Docker, CasaOS components and installed apps. Know how to restart services. Confirm the data path. Keep SSH access secure. Test backups. Document where compose files and application volumes live.
If the CasaOS host is only on your LAN, the threat model is smaller but not zero. If you expose services to the internet through Tailscale, Cloudflare Tunnel, a router port forward, a reverse proxy or a public domain, the host becomes part of your public security posture. Wallet services should be treated accordingly.
The app store is useful but not magic
CasaOS-AppStore is a real repository, not a mysterious catalog. It stores manifests. It has releases, pull requests, contributors and a large number of forks. The README tells contributors to test apps on their own CasaOS before opening a pull request, which is exactly the kind of practical gate a home-server app store needs.
CasaOS also supports third-party app stores. The official AppStore README points users toward additional store links, and the wider community includes repositories such as BigBearCasaOS and LinuxServer-oriented stores. These can be useful because they expand the available software and sometimes keep popular apps closer to current upstream images.
Third-party stores also expand your trust boundary. A store can change image tags, default volumes, ports, environment variables and update timing. If you install a Nostr or Lightning service from a third-party store, your security review includes that store. The fact that CasaOS can add it easily does not make it automatically trustworthy.
Use a simple rule: the more financial power an app has, the less you should install it blind. For a wallet, backend, bridge or payment bot, inspect the manifest like code. If you cannot explain the image, volumes, secrets, ports and update behavior to yourself, pause before putting real funds behind it.
Updates need special attention
CasaOS wiki guidance about compose apps with the `latest` tag is worth reading before you rely on store updates. The page says that since CasaOS 0.4.4, the Update action updates to the version specified in the CasaOS AppStore. If the installed image tag matches the store tag, the app may be considered current even when Docker Hub has a newer image behind the same `latest` tag.
That detail is easy to miss. Many self-hosted users assume `latest` means they will get the newest container whenever they click update. In practice, tag semantics, store manifests and local update behavior can disagree. For security-sensitive services, you need a deliberate version strategy.
Pinned versions give you repeatability. Floating tags give you convenience but can hide changes. Watchtower-style automation can help some containers but can also update a wallet service without you reading release notes. CasaOS gives you an interface; it does not choose your risk appetite.
Before hosting NWC-capable infrastructure, decide how updates happen. Subscribe to upstream releases. Know whether the CasaOS app store version lags. Test updates with small funds first. Keep a rollback path. For a wallet service, backup compatibility is as important as installing the new image.
Storage and backups decide recovery
CasaOS emphasizes file management and storage expansion, which fits its personal cloud audience. You can use it for media, documents, photo backups and application data. But application recovery depends on more than seeing files in a dashboard. Docker volumes and bind mounts need to be included in your backup plan.
For Nostr and Lightning services, identify state before you need it. A relay stores events. A wallet service stores account data, node information or encrypted secrets. LNbits may rely on a database. Alby Hub has its own state. A reverse proxy has certificates and config. If you back up only a visible media folder, you may not be able to rebuild the payment stack.
Also test restore, not only backup. Bring the service up on another machine or in a temporary directory, confirm it starts, confirm NWC connections behave as expected and confirm old invoices, transactions or permissions are still intelligible. A backup that has never been restored is a hope, not a recovery plan.
If you plan to migrate from CasaOS to ZimaOS, read the official migration guide before moving data. The ZimaOS documentation discusses file transfer and app migration with CTOZ. That is useful, but payment services deserve extra caution because secrets, volumes and network names can be more brittle than ordinary media apps.
Network exposure is the main risk line
A CasaOS box often starts as a friendly LAN dashboard. That is a good default. Problems start when services need remote access. A Nostr wallet service may need to stay online, a reverse proxy may terminate HTTPS, a relay may listen publicly, or a mobile user may want to reach the dashboard from outside the house.
Every public path should be intentional. Do not expose the CasaOS dashboard itself unless you fully understand authentication, HTTPS, firewall rules and update status. Prefer private networks such as WireGuard or Tailscale for administration. If a user-facing service must be public, expose only that service through a hardened proxy.
NWC reduces the need to expose a wallet web UI. The wallet service can connect to a relay and receive encrypted requests from clients. That is a useful security property. It does not mean the host can be neglected. The service still runs somewhere, holds credentials and can be compromised by host-level mistakes.
Keep the mental boundary clear: Nostr relays carry encrypted wallet requests, but your CasaOS machine stores the service that can satisfy them. If someone gets shell access, reads environment files or controls Docker, NWC encryption no longer protects the wallet from that host compromise.
Privacy is different from custody
Self-hosting often feels private, and CasaOS leans into that promise by giving you local control over services and data. That is valuable. But privacy depends on which apps you install, where they connect, what telemetry they send, which relays they use and whether third-party stores or cloud tunnels are in the path.
A Nostr wallet service adds another layer. The relay may not read encrypted request content, but it can see timing and pubkeys. The wallet backend sees payments. A provider-backed wallet sees account activity. A self-hosted node sees local state. CasaOS itself is the host, not the privacy guarantee.
For reader safety, separate questions. Who can see your CasaOS dashboard? Who can read files on disk? Who controls Docker images? Who operates the NWC relay? Who runs the Lightning backend? Who sees invoice metadata? Who can revoke a connection? Each answer belongs to a different part of the stack.
This is why CasaOS should be described plainly. It can help you own more of the stack, but ownership is only useful when you operate it. The dashboard should make responsibility visible, not make the stack feel safer than it is.
The ZimaOS migration question
The CasaOS site now explicitly points toward ZimaOS, and ZimaSpace documentation includes a CasaOS-to-ZimaOS migration guide. ZimaOS is positioned as a more focused NAS operating system with broader storage and server ambitions. For a new home-server build, that transition is not background trivia.
If you already run CasaOS happily, there is no automatic reason to panic. But if your plan includes payments, wallet services or relays, you should avoid building a long-term stack on assumptions from an older tutorial. Check whether the app you need is better supported on CasaOS, ZimaOS, Umbrel, Start9, RaspiBlitz, Unraid or a plain Linux server.
Migration is easiest before the machine holds valuable state. Once the server has wallet data, app databases, reverse-proxy certificates and NWC connections, migration becomes a real project. You need to move files, recreate containers, preserve secrets, reissue or test connections and prove that backups still restore.
A good deployment note should say which platform you chose and why, which apps are installed, where the data lives and how to move it. Future you should not have to rediscover that while a payment app is offline.
Where CasaOS fits beside other systems
CasaOS belongs in the same conversation as Umbrel, Start9, RaspiBlitz and Unraid, but each system has a different center of gravity. RaspiBlitz is deeply Bitcoin and Lightning oriented. Start9 focuses on personal-server services and packaging. Umbrel is a polished home-server app experience. Unraid is a storage and NAS operating system with a large app ecosystem.
CasaOS is lighter and more general. It is appealing when you want a friendly Docker dashboard on hardware you already have, especially for home media, files and simple app hosting. It does not give you the same Bitcoin-first assumptions as RaspiBlitz or some Start9 packages.
That can be a strength. If your Nostr use is one part of a broader home-server setup, CasaOS may feel more natural than a Bitcoin-only appliance. It can host the wallet-related service next to normal household services, provided you keep the risk boundaries clear.
It can also be the wrong fit. If you want opinionated Bitcoin node management, guided wallet backups, integrated Tor defaults or service recipes maintained specifically for Lightning infrastructure, compare the alternatives. The easiest dashboard is not always the best operator model.
What to verify before using it for NWC
Start with the exact app. Do not say you are using CasaOS for NWC and stop there. Name the wallet service, backend and version. Confirm whether it officially supports NIP-47, which methods it supports, how it creates NWC connections, where budgets live and how revocation works.
Then inspect hosting details. Check the CasaOS version, base OS, Docker version, app store source, compose manifest, image tag, mounted volumes, exposed ports, environment variables, update behavior, logs, backup path and restore process. If any one of those is vague, write it down and resolve it before using meaningful funds.
Next test payments with low value. Create an NWC connection with a small budget, pay an invoice, create an invoice if supported, restart the CasaOS host, confirm the service returns, verify logs, check whether the app recovers cleanly and make sure revoked connections no longer work.
Finally decide what the user is allowed to believe. If someone else will connect an app to your CasaOS-hosted wallet service, tell them whether the backend is self-custodial, provider-backed, custodial, experimental or limited. Trust improves when the product is honest about what it is.
Who should consider CasaOS
CasaOS is a sensible option for a reader who wants a friendly self-hosting dashboard, already has suitable hardware, is comfortable with Docker basics and wants Nostr or Lightning services as part of a broader personal cloud. It is especially good for learning how wallet infrastructure sits beside normal home-server infrastructure.
It is less suitable for someone who wants a turn-key Bitcoin node appliance, a managed wallet, a commercial SLA, or a system where every Nostr and Lightning service is curated by a Bitcoin-focused team. CasaOS gives you control and convenience, but it does not remove operator judgment.
The most practical use is gradual. Install CasaOS on a non-critical machine, learn the dashboard, add harmless apps, inspect compose files, test backups, then add one NWC-capable service with a small budget. If that rhythm feels boring, it is doing its job. Payment stacks should become exciting only after the basics are boring.
The final takeaway is simple: CasaOS is not the wallet. It is the place where the wallet service may live. Treat it like infrastructure, keep the app store and Docker layer visible, and your Nostr Wallet Connect setup will be much easier to understand when something needs updating, moving or repairing.
Sources worth opening
Start with the CasaOS site, the CasaOS and CasaOS-AppStore repositories, ZimaOS migration documentation and the NWC ecosystem list. Then read CasaOS wiki notes and issue history before putting a wallet or payment service behind the dashboard.
- CasaOS official site
- CasaOS GitHub repository
- CasaOS GitHub API metadata
- CasaOS releases
- CasaOS README
- CasaOS go.mod
- IceWhaleTech GitHub organization
- CasaOS-AppStore repository
- CasaOS-AppStore GitHub API metadata
- CasaOS-AppStore releases
- CasaOS third-party app stores list
- BigBear CasaOS app store repository
- LinuxServer CasaOS app store repository
- CasaOS wiki: manually update compose app with latest tag
- CasaOS wiki development contribution guide
- CasaOS discussion: CasaOS is not an OS
- CasaOS discussion: how to update Docker applications
- CasaOS issue: app store does not load
- CasaOS issue: installation on Ubuntu and SUSE
- CasaOS issue: installation script distribution detection
- ZimaOS official page
- ZimaOS GitHub repository
- ZimaOS GitHub API metadata
- ZimaSpace migration guide from CasaOS to ZimaOS
- ZimaSpace docs
- getAlby awesome-nwc embedded operating systems list
- Nostr Wallet Connect website
- NIP-47 Nostr Wallet Connect
- Alby NWC developer guide
- Alby Account app connections via NWC
- Alby Hub official site
- LNbits official site
- Docker Compose documentation
- Docker bind mounts documentation
- Docker volumes documentation
- Reddit CasaOS app store outdated discussion
- Reddit CasaOS app store broken after Docker update
- BigBear community Immich update discussion
- Techno Tim CasaOS ZimaBoard project overview
- TechRadar ZimaCube 2 review with ZimaOS context
