Preview refresh behavior limits developer iteration speed in Pulumi

Question

Developers want `pulumi preview` to show an accurate drift detection without manually adding `--refresh` each time, so that the preview step remains reliable in a repeatable development workflow. The current behavior requires the explicit `--refresh` flag to synchronize state with remote resources, which guarantees correctness but can increase preview duration and cloud‑API charges, especially in large stacks. Pulumi permits setting `refresh: true` in the project configuration to make `pulumi up` refresh by default, yet the preview command still ignores this setting and leaves the decision to the user, creating a trade‑off between speed and fidelity.
Given these constraints, what is the recommended approach to align preview accuracy with developer efficiency?

Should the project‑level `refresh: true` setting automatically apply to `pulumi preview`?
Would introducing a `--refresh‑preview` flag or a new configuration option provide a better balance?
Is there a way to cache refreshed state across successive previews to mitigate latency while preserving correctness?

Tasadduq Burney · Answer

Answer the Question First
In short, the current best practice is to keep refresh: true for pulumi up only, and use pulumi preview --refresh when you need a drift‑aware plan. Pulumi does not yet support a project‑level previewRefresh: true or a dedicated --refresh-preview flag, and there is no built‑in cache that persists refreshed state across preview runs.

Why the Behavior Exists

The preview command is designed to be a lightweight planning step that avoids unnecessary cloud‑API calls.
Automatic refresh would add latency and cost to every preview, which many teams run frequently during development.
Keeping preview fast enables rapid iteration on code changes without waiting for a full state sync.

Recommended Approach for Your Workflow

Use pulumi preview --refresh for critical drift checks. When you are about to deploy or when you suspect external changes, run pulumi preview --refresh to guarantee the plan reflects the current cloud state.
Enable refresh: true only for pulumi up. This keeps normal deployments up‑to‑date while preserving preview speed.
Consider a short‑lived local cache (TTL 5‑10 min). If you frequently run preview in a single developer environment, you can implement a simple wrapper script that stores the result of a --refresh run and reuses it for subsequent previews until the TTL expires. This reduces API calls while still catching recent drift.
Monitor API usage. Use your cloud provider’s cost and request metrics to verify that adding --refresh does not exceed your budget. If it does, adjust the cache TTL or limit the number of preview runs per day.

Potential Future Enhancements

Pull requests for a previewRefresh configuration option or a --refresh-preview flag are welcome in the Pulumi repo.
Community discussions on balancing cost vs. fidelity can inform the next release cycle.

Next Diagnostic Step (If Needed)
If you are experiencing unexpected drift that is not caught by pulumi preview, confirm the following:

What is your current Pulumi CLI version? (pulumi version)
Do you have refresh: true set in Pulumi.yaml?

Providing these details will help refine the recommendation further.

Preview refresh behavior limits developer iteration speed in Pulumi

1 answer

Answer the Question First

Why the Behavior Exists

Recommended Approach for Your Workflow

Potential Future Enhancements

Next Diagnostic Step (If Needed)

Your perspective belongs here.

1 question comment

Targeted refresh reduces API surface

Schedule refresh in CI, not locally

Verify version-specific behavior