A Docker image is a built filesystem and program ready to run. A container is a running image instance. Git stores source; a registry stores images; *.images.tar is a file containing copies of them. These are different things.
What the application uses
| Image | Purpose | Operation |
|---|---|---|
| backend | Go API, migrate for SQL, admin for the first account | API runs continuously; migrate/admin run for individual actions |
| admin | Built React interface and Nginx | Persistent frontend container serves UI and API proxy |
| ops | Configuration checks, operation state, dumps, and restore | Temporary service containers during control commands |
| postgres:16-bookworm | PostgreSQL server | Persistent database container with data outside the image |
| certbot | HTTPS certificate issuance and maintenance | Runs for certificate work |
| nginx | Base Nginx image and configuration checks | Used by frontend and its checks |
A standalone website hosted alongside the application has its own image and container. It is not an old admin version.
What ops is for
deploy/control calls ops to check settings and releases, record operation stages, generate configuration, check API readiness, create dumps with pg_dump, and restore them with pg_restore. Ops also contains PostgreSQL client tools, OpenSSL, curl, jq, and the admingen-ops operator. Application migrations run through migrate in the backend image.
Ops currently uses postgres:16-bookworm, like the database image. No PostgreSQL server runs inside ops: the base supplies ready-made tools of the same version. A smaller ops is not yet implemented. Docker stores shared layers once, so image list sizes cannot simply be added.
Ops remains necessary for management commands even with backup None. It is not disposable merely because no persistent ops container exists. Preserve exact current and previous release ops images together with backend and admin.
Build images
Go and Node compile source inside intermediate Docker stages. They are not separate persistent application containers and are not included in full in final backend/admin/ops. Build leaves cache and sometimes base images to speed up the next build. Source needs no private registry, but Docker still obtains missing base images from external sources.
View actual containers
On the machine running the application:
docker ps -a --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'
docker image ls
For a selected container, substituting its name from the first command:
docker inspect ИМЯ_КОНТЕЙНЕРА --format 'Image={{.Image}} Configured={{.Config.Image}} Status={{.State.Status}}'
Old image tags do not prove extra containers exist. Previous images are retained for recovery after release; cleanup is covered separately.
If a required image was deleted
For Source/Archive, restore images from the saved current release archive:
docker load -i /полный/путь/к/релизу.images.tar
Take the path from the imageArchive field in state/current.json and the archive's actual location. In runtime, the filename is the record's SHA256 plus .tar. Loading restores images without restarting the application. For Registry, use docker pull on the exact image reference from the release record. Do not replace a lost image with a new build under the old tag.