Hi ZimaOS team,
I would like to request native management of local Docker images directly from the ZimaOS web UI.
Currently, ZimaOS provides a very convenient interface for managing Docker applications, but there is no proper UI for Docker images that already exist locally on the machine.
Current problem
For example, I can build an image directly on ZimaOS:
docker build -t my-app:latest .
or import one:
docker load -i my-app.tar
The image exists locally and can be seen with:
docker image ls
However, ZimaOS does not provide a UI where I can see and manage these images.
More importantly, when creating a custom app, it should be possible to select an image that already exists locally instead of expecting it to come from an external Docker registry.
This currently forces users who develop or deploy their own applications to use the CLI or install tools such as Portainer just to manage Docker images.
Suggested functionality
A new Docker Images section in ZimaOS could provide:
- List of all locally available Docker images
- Repository and tag
- Image ID
- Image size
- Creation date
- Ability to use a local image when creating a custom app
- Import an image from a .tar file (docker load)
- Delete unused images
- Tag/rename images
- Show which containers/apps are using each image
An especially important behavior would be:
If the requested image already exists locally, ZimaOS should allow the user to use it without requiring a pull from an external registry.
Example workflow
Source code
↓
docker build -t my-app:latest .
↓
Local Docker image on ZimaOS
↓
ZimaOS UI → Docker Images
↓
Select my-app:latest
↓
Create / manage application
Why this matters
ZimaOS is already very convenient for Docker-based applications, but this missing layer of image management makes the experience incomplete for users who build their own software.
For many homelab users and developers, installing Portainer only to inspect, select, import or delete local Docker images feels unnecessary.
A simple image-management interface integrated into ZimaOS would close this gap and make the built-in Docker experience significantly more complete.
Thanks for considering it.