The October 2025 architecture post is useful because it tries to connect hardware, the Linux base, Docker, storage, networking, applications, and monitoring into one mental model. It is also a good example of why community reverse-engineering should not be mistaken for an official internal specification.
The author renamed the post “My Observation” and corrected several details after other users challenged them. A high-quality summary should preserve those corrections and verify only the core claims that are supported by IceWhale's own current sources.
ZimaOS Is Buildroot-Based, Not a General-Purpose Debian Install
The most important correction in the thread was the base operating system. The post initially prompted questions about Debian, then the author corrected it to Buildroot. IceWhale's public ZimaOS repository independently confirms that the system is built with Buildroot and designed around stable OTA updates.
You can verify that foundation in IceWhale's current public ZimaOS project description.
The Supported Platform Focus Is x86-64
The source post lists Intel and AMD x86-64 hardware and says there was no official ARM build at the time. IceWhale's current public project still describes Zima hardware and generic x86-64 systems with UEFI as supported targets.
That makes x86-64 a stable architectural fact; individual NIC, GPU, storage-controller, and sensor support still depends on the actual hardware and ZimaOS release.
Applications Are Built Around Docker Compose
The community post described Docker as the application layer. Current ZimaOS app-store specifications confirm that app definitions are authored as Docker Compose with ZimaOS-specific x-casaos metadata layered on top.
The useful design rule is simple: runtime container settings stay in Docker Compose while ZimaOS store metadata lives in x-casaos.
App Data Lives Outside Disposable Containers
One practical consequence of the container model is that important application data should be mapped to persistent storage. Current ZimaOS guidance recommends keeping valuable app data on storage space rather than filling the smaller system drive.
This is more actionable than relying on a fixed list of internal paths from a 2025 architecture observation because App Store packaging and storage behavior can evolve independently.
The Local Hostname Correction Was zimaos.local
The thread originally used zima.local. Another user tested it and showed that the working local name was zimaos.local, which the author then corrected.
zima.local to zimaos.local.Do Not Freeze Community-Observed Internal Service Names
The original post listed specific service names, ports, monitoring components, RAID locations, and optional filesystem tooling. Some may have been accurate in a particular build, but they are not all stable public contracts.
For long-lived search content, the safer architecture model is the supported boundary: Buildroot appliance OS, Docker-based applications, managed storage and networking, OTA updates, and a web/client management layer. Treat deeper service names as implementation details unless IceWhale publishes them as an API or compatibility contract.
ZimaOS Architecture FAQ
Is ZimaOS Debian?
No. The community author corrected that claim, and IceWhale's public project identifies ZimaOS as Buildroot-based.
Does ZimaOS use Docker for apps?
Yes. Current ZimaOS app-store specifications are based on Docker Compose plus ZimaOS metadata.
Is every internal service name in the 2025 post guaranteed?
No. The post is explicitly an observation and was corrected after publication. Internal components can change between releases.
What local hostname should I try?
The corrected hostname in the thread is zimaos.local, though direct IP access remains useful when local discovery is unavailable.
