Why imglife?
imglife turns Docker image management from a patchwork of fragile scripts and tribal conventions into a declarative, auditable, industrial-grade system — one YAML, one binary.
The four structural problems
Section titled “The four structural problems”Any organization running Docker at scale eventually hits the same four pain points:
- Dependency on public registries — Docker Hub rate limits, images silently removed, unpatched CVEs.
- Base image drift — every team rebuilds its own Dockerfiles: inconsistency, duplication, security gaps.
- Registry sprawl — tags never purged, storage costs drifting, impossible to tell what’s actually used.
- Lack of traceability — which app uses which base? which version? is it EOL?
imglife addresses all four with a single tool and a single YAML file, instead of stitching together four or five heterogeneous tools (Skopeo + Harbor policies + bash scripts + homegrown dashboards).
Benefits by role
Section titled “Benefits by role”Application developer
Section titled “Application developer”You want to ship code, not maintain Dockerfiles.
- One less Dockerfile to maintain — consume a validated base from the platform and focus on your application.
- Faster, more reliable CI — internal pulls (no Docker Hub rate limits), bases already cached close to your runners.
- Immediate feedback if your base is outdated —
imglife checkfails your pipeline before an outdated runtime reaches production. - No coordination overhead — when the platform patches a base, you pick it up at your next build.
Platform / DevOps team
Section titled “Platform / DevOps team”You’re responsible for the organization’s image hygiene.
- Enforceable standardization — Dockerfile templates become the single contract for every org image.
- Cascading updates — patch a base, all applicative projects detect it on their next build, no broadcast email required.
- Measurable time savings — managing 50+ images (sync, tag, purge, docs) drops from hours per week to near-zero once the YAML is written.
- Config-as-code — the YAML lives in Git, reviewed via MR, with full history and trivial rollback.
Security / CISO
Section titled “Security / CISO”You need to prove the supply chain is under control.
- Reduced attack surface — one single, audited entry path for external images.
- Automatic EOL tracking — alert before a critical CVE lands on an unsupported version, via endoflife.date integration.
- Credentials outside configuration — the YAML can live in Git in the clear; tokens stay in the CI vault.
- End-to-end traceability — build records in the Package Registry — useful for SOC 2 / ISO 27001 audits.
Engineering leadership / FinOps
Section titled “Engineering leadership / FinOps”You care about the organization’s bottom line.
- Controlled storage costs — automatic retention (
cleanup,app purge) keeps the registry from growing into a 2 TB monster. - Reduced human cost — no in-house project to keep alive (bash scripts, custom Terraform, homegrown dashboards).
- Short time-to-value — one YAML file, one GitLab pipeline, and it’s running. No heavy platform to install.
- Low lock-in — provider-agnostic: GitLab, Gitea, Docker Hub, any OCI registry.
Structural advantages
Section titled “Structural advantages”| Advantage | Concrete consequence |
|---|---|
| Config-as-code (single YAML) | Review via MR, Git history, trivial rollback |
| Three-tier (mirror/base/app) | Separates responsibilities → fewer inter-team conflicts |
| Stateless & idempotent | Replaying a pipeline is safe, no hidden drift |
| Extensible hooks | Integrates with existing tooling (Slack, Jira, Cosign signing) |
| Provider-agnostic | GitLab, Gitea, Docker Hub, generic OCI registries |
What you get vs. rolling your own
Section titled “What you get vs. rolling your own”- Guaranteed consistency across sync, build, cleanup, and status — no windows where a tag exists without a build record.
- Batched Docker Hub API calls (tags + dates in a single request) — the kind of optimization rarely done in an in-house script.
- Exponential retry built in everywhere — network resilience without custom code.
- Bilingual documentation — adoptable in mixed EN/FR teams without friction.
What imglife is not
Section titled “What imglife is not”Being explicit about the boundary is a feature:
- It is not a vulnerability scanner — pair with Trivy or Grype.
- It is not a registry — it orchestrates, it does not store.
- It is not a native signing tool — but hooks let you plug Cosign into the pipeline.
imglife does one thing, well, and integrates with the rest of your stack.
One-sentence summary
Section titled “One-sentence summary”imglife makes Docker image management declarative, auditable, and industrial-grade, with a low adoption cost and fast ROI as soon as you manage more than ~10 images.