Failure Can Be A Great Teacher

I flew too close to the Sun

I looked this up on Wikipedia:

Icarus was the son of Daedalus, who escaped from Crete with wings made of feathers and wax. He ignored his father’s warning not to fly too close to the Sun and fell into the sea, giving rise to the idiom “fly too close to the Sun“.

Sunday evening, I had my Icarus moment. Feeling super confident after two days of moving self-hosted apps from CasaOS to Docker Compose, I flew too close to the sun and melted my wings right off.

Leading up to that moment, I had successfully moved several apps from CasaOS to Docker Compose. Here is where things stood with my homelab.

============================================================
PRIMARY: NukBox K10 (Pop!_OS)
Specs: Intel i9-13900HK | 98GB RAM | 4TB NVMe SSD
============================================================
|
├── Docker Compose (The Liberated Fleet)
│ ├── Portainer
│ ├── Immich
│ ├── Paperless-ngx
│ └── Joplin Server
|
└── CasaOS Dashboard (The Legacy Fleet)
    ├── Calibre
    ├── Calibre-web
    └── Home Assistant

============================================================
AI/LOCAL LLM: 2020 Mac Mini (macOS)
Specs: Apple M1 | 16GB RAM | 1TB SSD
============================================================
|
└── Docker Desktop
    └── Ollama (Containerized)

============================================================
PLAYGROUND: ThinkStation P310 (Fedora Server 43)
Specs: Intel i7-6700 | 48GB RAM | 512GB SSD (Boot)
============================================================
|
├── ZFS Storage (The “Mirror” Pool)
│ └── 3TB Usable (4TB HDD + 3TB HDD Mirrored)
|
└── Podman / Cockpit
    ├── Syncthing (not configured yet)
    ├── Calibre (not configured yet)
    └── Joplin Server (not configured yet)

I knew Calibre and Home Assistant were disposable, so I proceeded to uninstall Home Assistant from CasaOS. That’s when it got dicey. Here is Gemini’s recap of why that simple “delete” turned into a ghost hunt:

The “CasaOS vs. Home Assistant” breakdown

Issue	What actually happened
The “Ghost” Container	CasaOS is just a visual wrapper. Even when you “deleted” the app in the UI, the underlying Docker container was often stuck in a ‘Restarting’ loop or locked by a process, making it reappear.
Orphaned Volumes	Home Assistant creates massive folders for its database and configuration. CasaOS often deletes the container but leaves the Docker Volumes behind. These kept your old settings “haunting” any new installation.
App Store Desync	Because you were likely using the “BigBear” or 3rd-party App Stores, the uninstall script provided by the store didn’t always match the version of Home Assistant you had running.
Permissions Lock	Home Assistant often runs with “Privileged” access to talk to your Zigbee/Z-Wave sticks. This gives it root-level file permissions that CasaOS’s standard user didn’t have the “strength” to delete without sudo.
Port Conflicts	Even after “deletion,” the service often held onto port 8123. When you tried to reinstall or move on, the system would error out because it thought Home Assistant was still there.

From there, things just got worse. My new “Liberated Fleet” stopped loading. I panicked and downgraded Docker to fix a known CasaOS bug. No luck.

When AI leads you astray

I decided to sunset CasaOS entirely and consulted with Gemini.

Me: I’m tired of working around CasaOS. I just uninstalled Home Assistant from CasaOS. I have all my ebooks on my drive that can be reimported into a new instance of Calibre. So can I uninstall CasaOS and then added Calibre to Docker Compose?

Gemini: I hear you. There is a specific kind of “homelab fatigue” that sets in when you spend more time fixing the management layer (CasaOS) than actually using your apps.

Uninstalling CasaOS and moving to a pure Docker Compose setup is the “grown-up” move for your homelab. It gives you total control, zero hidden dependencies, and makes your NukBox significantly more stable.

Here is the “clean break” plan to get Calibre running and finally sunset CasaOS.

The “Clean Break” (Uninstall CasaOS)

Since you’ve decided to move on, let’s remove the middleman. CasaOS has an official uninstall script. Run this to reclaim your system:

Bash

sudo casaos-uninstall

Note: This usually leaves your Docker containers running but removes the CasaOS dashboard and its custom management scripts.

Me: Before i do that, I have all my Documents under Computer/DATA/Documents. Likewise, all my Picutres are under Computer/DATA/Pictures. Do I need to move those folders/files to a different home folder?

Gemini: No, you definitely do not need to move them. In fact, it is better to leave them right where they are on your DATA drive.

The beauty of Docker is that it doesn’t care where your files live on the physical disk; you just tell the container where to look using Volume Mapping.

More headache ensued trying to see all my apps in Portainer.

Me: What if i just uninstalled CasaOS completely?

Gemini: Actually, that is exactly what I was thinking. CasaOS is likely the “ghost in the machine” right now. It has a habit of leaving behind hidden background services and firewall rules that squat on ports like 9443 and 9000, which is why your new Portainer is having a “bind” error.

Since you’ve moved to managing things via Cockpit and Portainer, CasaOS is just overhead you don’t need.

Spoiler alert: This was terrible advice.

The Meltdown

When I ran the script, it asked, “Do you want to delete all containers?” and I selected “Y.”

I assumed the script was “CasaOS-aware”—meaning it would only delete the apps it managed. In reality, the script was a “Docker-aware wrecking ball.” It didn’t care that I had spent 48 hours manually building a “Liberated Fleet” in Portainer. It saw containers, and it executed them.

All the work done in the previous two days was erased. My wings didn’t just melt; they were incinerated.

Lesson learned: Failure can be a cruel teacher, but it can also be a great teacher. Perhaps both.

Using an AI like Gemini for a homelab migration is helpful, but it has its limits. It’s like having a technical assistant who knows the manuals but lacks the context of your specific environment.

• Where AI helps: It’s an excellent translation tool. It took my CasaOS configurations and turned them into clean Docker Compose files in seconds, saving me a lot of manual work.
• Where AI fails: It has a “best-case scenario” bias. It recommended the casaos-uninstall script assuming it would be a surgical removal. It didn’t warn me that the script’s default behavior was to wipe every container on the system, including the ones I had manually built.

The Importance of “Snapshotting” Your Progress

The biggest takeaway wasn’t just about the AI, but about my own workflow. I got caught up in the momentum and skipped the most basic safety step: creating a backup before a major change.

Moving forward, I’m adopting a “Snapshot before you Strike” rule:

1. Config Backups: Save a copy of my .env and docker-compose.yml files to a separate drive or GitHub before running any uninstallers.
2. Verified State: Before removing a management layer like CasaOS, double-check that the “new” fleet is fully documented and backed up elsewhere.

The New Rule: Trust the logic, but verify the script. AI is great for explaining concepts and syntax, but before running a “Cleanup” command, it’s worth reading the source code of that script or asking someone who has run it before. It’s a lot easier to take a five-minute backup than it is to spend two days rebuilding a fleet from scratch.

---

P.S. Update: After the unfortunate series of events resulting in no functioning containers, I started moving apps one by one to my Fedora Server using Cockpit and Podman. Currently pushing 285GB of photos into a new Podman instance of Immich storing my precious photos and videos on a ZFS mirror. The wings are being rebuilt—this time with ZFS snapshots for feathers. Stay tuned for that progress update!