The old CasaOS Coolify tutorial is still useful as a pointer to the project, but it is not a drop-in installation recipe for current ZimaOS. The key difference is that Coolify expects SSH key access back into the server it manages, while ZimaOS protects parts of its base system as read-only.
In the 2026 follow-up to the forum thread, the blocker was exactly this: Coolify asked for its public key to be copied into ~/.ssh/authorized_keys, but the user could not find a normal writable root SSH path. Treat this as a platform-integration issue, not as evidence that Coolify itself is broken.
Why the CasaOS Guide Does Not Map Directly to ZimaOS
Coolify's current documentation says a self-hosted server needs SSH access and that the public key used by Coolify should be authorized for the account it manages. Its installer also creates data under /data/coolify and expects to manage Docker on the host. Those assumptions are normal on a conventional Linux server.
ZimaOS, however, is an appliance-style NAS operating system. The official ZimaOS SSH guide shows how to enable SSH from Developer Mode, but it does not promise that every conventional Linux path is writable or persistent across system updates.
What Coolify Requires Today
The current Coolify installation guide lists a 64-bit Linux server with SSH access, Docker support, at least 2 CPU cores, 2 GB of RAM and 30 GB of free storage. It also recommends a fresh server to reduce conflicts with existing services.
Coolify uses SSH even when it is managing the same machine on which Coolify runs. Its OpenSSH setup documentation specifically expects key-based authentication. That is why simply importing a CasaOS app definition does not eliminate the host-side SSH requirement.
Safer Deployment Paths on a ZimaOS Home Server
If you want Coolify mainly for application deployments, the cleanest design is to run it on a Linux environment that matches Coolify's supported assumptions, such as a dedicated Debian/Ubuntu server or VM, and let ZimaOS continue to handle NAS storage and other services. This keeps Coolify's host-level changes away from the protected ZimaOS base system.
If you still want to experiment directly on ZimaOS, first make a backup of application data and confirm exactly where SSH keys and Coolify state will persist. A community learning repository documents the ZimaOS-specific work in progress, but it should be treated as community experimentation rather than an IceWhale-supported installation path: ZimaOS Coolify learning repository.
For users building a small always-on deployment host, a compact home server can provide the x86 hardware layer, while the operating-system choice should still follow the software you intend to run.
Bottom Line
The forum thread does not establish a one-click Coolify-on-ZimaOS method. It establishes the opposite: the CasaOS recipe reaches an SSH persistence boundary on ZimaOS. Use current Coolify requirements as the source of truth, and isolate Coolify in a conventional Linux environment when you want the most predictable upgrade and recovery path.
