Support time-based image pull policies (Daily / Weekly / Every(duration)) in ImagePullPolicy

[jeremad]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Summary

ImagePullPolicy currently exposes only Default, Always, Missing, and Never. There is no way to express a periodic refresh. Docker Compose already supports exactly this via time-based pull_policy values (daily, weekly, every_<duration>). This issue requests parity in Aspire's ImagePullPolicy.

Motivation

A very common local-dev / CI pattern is a container pinned to a mutable tag such as :latest that an upstream pipeline rebuilds roughly once a day:

builder.AddContainer("mock", "registry.example.com/org/mock-service", "latest")
    .WithLifetime(ContainerLifetime.Session);

Today the available options are both unsatisfying:

• Missing / Default — the cached :latest is reused forever and silently goes stale; you never pick up the daily rebuild unless you manually docker pull or prune.
• Always — re-pulls on every aspire run / startup. That adds pull latency to every launch and fails hard with no network (see Keeping referenced containers automatically up to date #10719), even though a day-old cached image would have been perfectly fine.

What's actually wanted is "keep it reasonably fresh, but don't pay the pull cost on every start".

What Docker Compose already does

The Compose spec supports time-based pull policies:

• daily: check the registry if the last pull was more than 24h ago
• weekly: same, for 7 days
• every_<duration>: every_12h, every_2d, every_1h30m

Docs: https://docs.docker.com/reference/compose-file/services/#pull_policy

Because Aspire maps WithImagePullPolicy(...) onto the generated Compose pull_policy when publishing to a Docker Compose environment, the current enum can't even emit these values today.

Describe the solution you'd like

Proposed API

Add time-based members / a factory to ImagePullPolicy, e.g.:

// convenience presets
builder.AddContainer("mock", "registry.example.com/org/mock-service", "latest")
    .WithImagePullPolicy(ImagePullPolicy.Daily);

builder.AddContainer("mock", "registry.example.com/org/mock-service", "latest")
    .WithImagePullPolicy(ImagePullPolicy.Weekly);

// arbitrary interval
builder.AddContainer("mock", "registry.example.com/org/mock-service", "latest")
    .WithImagePullPolicy(ImagePullPolicy.Every(TimeSpan.FromHours(12)));

Semantics: before creating the container, if the locally cached image's pull/creation time is older than the interval, pull; otherwise reuse the cache.

Relationship to existing issues

• Keeping referenced containers automatically up to date #10719 (ImagePullPolicy.IfPossible) is related but orthogonal: it asks for "pull if the network is available, otherwise fall back to cache." A time-based policy is about how often to attempt a pull, not about network-failure fallback. Ideally the two compose.
• Expose Image Pull Policy on Containers #7350 exposed WithImagePullPolicy in the first place (13.2).

Additional context

Aspire ImagePullPolicy members as of today: Default, Always, Missing, Never

[joperezr]

🤖 Aspire triage pass — 2026-08-24 10:27 UTC

Area: area-app-model, area-orchestrator
Kind: feature-request
Repro: none — enhancement request (proposed API shown in body)
Affected version(s): N/A — feature request; WithImagePullPolicy shipped in 13.2, current members are Default/Always/Missing/Never (latest: 13.4.0)
Severity: S4 — enhancement/parity request; workarounds exist (Always, or manual pull/prune)

Urgency: ⚪ backlog — no milestone
Reason: feature request (no milestone while 13.5 stabilizes)

Suggested owner(s): Karol Zadora-Przylecki (@karolz-ms) (score ~14), backup James Newton-King (@JamesNK) (score ~9)
Evidence:

• karolz-ms merged Simplify and improve Executable launch argument computation #19552, Improve handling of log deduplications #19204, Separate regular arguments from launch tool ("entrypoint") arguments #18999, Improve handling of object change notifications during local run #19079, Properly process object update notifications from DCP #18952 in area-app-model (last 30d, recency-weighted)
• karolz-ms closed [13.5] Regression - Persistent Resource no longer starts after upgrade #19194, WithDebugSupport argument rewriting is order-sensitive and mutates the app model #18929, DCP continuously emits modified notifications for containers that aren't running #18869, WaitBehavior.StopOnResourceUnavailable hangs if referencing a resource that doesn't exist #17267 as completed in area-app-model
• JamesNK merged Harden interaction file uploads #19488, Stop redisplaying dismissed unresolved parameters notification #19336, Move progress prompt title to options #19382, Warn when version update notification cannot be ignored #19162 in area-app-model (last 30d) and closed File input: MaxFileSize XML doc should mention Dashboard's 1MB default fallback #18659, [13.3] Interaction Service is unaware if command is invoked from CLI #16720 as completed
• CODEOWNERS: no path-specific match (issue cites no repo file paths)

Confidence: high
Needs human?: no

[afscrome]

These time based image pull policies aren't supported by Kubernetes, nor docker container run --pull.

It's also worth noting that these options only got added to docker compose a week or so ago - https://github.com/docker/compose/releases/tag/v5.5.0 , so care should be taken as they won't be supported by all sources a user may deploy docker compose to.

I'm tempted to say that these time based refresh ought to be a separate concept rather than overloading the existing WithImagePullPolicy. Potentially even one configured application wide - if you want to refresh out of date mutable tags, do you really want to specify different values for each individual container, or just have one builder.RefreshContainersOlderThan("1d") method?