Current Answer: Bring Your Own Docker Compose—Do Not Assume You Must Add a Third-Party Store
The thread suggested adding a LinuxServer repository and searching for KiCad. That can work when a compatible catalog already packages the app, but current ZimaOS documentation also supports bringing your own Docker Compose. For a one-off app, that is often clearer than turning a whole third-party repository into a dependency.
First Find an Upstream Container Definition You Trust
For KiCad, LinuxServer publishes a maintained container with persistent /config, a web desktop and documented architectures. Read the LinuxServer KiCad documentation before copying a random Compose file.
ZimaOS App Packaging Is Standard Compose Plus x-casaos Metadata
The current Docker Compose and x-casaos reference separates normal Docker runtime configuration from ZimaOS store metadata. The upstream Docker Compose reference remains the source of truth for services, volumes, ports and environment variables.
Keep Persistent App Data Outside the Container
Map KiCad configuration/projects to persistent storage and verify the host path before installing. The ZimaOS app path guide explains why container deletion should not delete properly mapped user data.
Use a Store Only When You Want Repeatable Catalog Installation
If you plan to maintain several custom apps, then building or adding a compatible store makes sense. The ZimaOS v2 repository model uses Apps/<AppName>/docker-compose.yml plus generated metadata. For one app, Compose is the simpler abstraction.
The Portainer hardware guide and ZimaOS App Store hardware directory are useful when the custom-app stack grows.
Do Not Modify the ZimaOS Base System to Install a Desktop App
KiCad belongs in a container/VM, not as an apt install on the ZimaOS host. The ZimaOS package-manager guide explains that boundary.
