Community Solution

Edit Docker Compose for Installed ZimaOS Apps: What Changed with App Store 2.0

A January 2026 discussion about adding Traefik labels and custom DNS to installed ZimaOS apps. IceWhale said it was refactoring the App Store to add direct YAML editing; ZimaOS 1.7.0 later introduced native YAML support.

In January 2026, users who installed an app from the ZimaOS App Store could change exposed settings such as ports, environment variables, and volumes, but did not have the same Compose-level control as a stack they owned themselves. That became a problem for advanced settings such as Traefik labels, shared networks, middleware, or container-specific DNS.

The important update is that the thread's roadmap is no longer purely future tense. IceWhale said it was refactoring the App Store to add Docker Compose YAML editing, and ZimaOS 1.7.0 later shipped native YAML support.

Why App Store Apps Were Hard to Edit in Early 2026

The community explanation was that store-installed apps were managed by ZimaOS. Editing generated Compose outside that management path could be overwritten by redeploys or upgrades.

For advanced users, the practical workaround at the time was to install the service as Custom Compose, keep the same persistent AppData folders, and manage the Compose stack yourself with a tool such as Dockge or Portainer.

Advanced Reverse Proxy Settings Need Compose-Level Control

The original user specifically wanted Traefik labels and a way to force selected containers to use Cloudflare DNS instead of Pi-hole. Those are normal Docker Compose concerns rather than simple app-title or port settings.

Current ZimaOS app-store specifications make this boundary explicit: standard runtime configuration belongs in Docker Compose while ZimaOS-specific store metadata belongs in x-casaos.

IceWhale Confirmed a YAML Editor Was Planned

Zima-Jerry replied that the team was refactoring the App Store and installation experience so a simple installation path could coexist with advanced Docker Compose YAML editing.

That official reply is more authoritative than the earlier community assumption that store apps could never be edited directly.

ZimaOS 1.7.0 Added Native YAML Support

By July 2026, ZimaOS App Store 2.0 shipped an app management redesign and native YAML support for more flexible application configuration. Current ZimaOS also centralizes installed-app status, updates, and common settings on the app management page.

The current App Store overview shows how installed apps are now managed from the redesigned ZimaOS application interface.

Native YAML Does Not Mean Every External Stack Is Managed Automatically

The new editor improves control over ZimaOS-managed applications, but that should not be confused with full ownership of arbitrary Compose stacks started outside the ZimaOS app system. Current 1.7.x reports still distinguish manually launched Compose groups from apps that ZimaOS manages itself.

Preserve AppData When Changing Ownership Models

If you deliberately move an app from a managed store package to a self-managed Compose stack, the important data is normally in its persistent host folders. Back those up first, then reproduce the same volume mappings, ports, environment values, and database dependencies before removing the old container.

Do not assume that recreating a container automatically migrates every ZimaOS-specific setting or secret.

Editing ZimaOS App YAML FAQ

Was direct Compose editing available when the thread was posted?

Not in the way the user wanted. The community workaround was Custom Compose, while IceWhale said direct YAML editing was being developed.

Did ZimaOS eventually add native YAML editing?

Yes. ZimaOS 1.7.0 announced native YAML support as part of the App Store 2.0 redesign.

Should I still use Dockge?

It can still make sense when you intentionally want to own an independent Compose stack rather than have ZimaOS manage the application.

Can I keep existing application data when switching to Custom Compose?

Often yes if the persistent host folders are preserved and remapped correctly, but back up the data and record the original container settings first.