Archiving workspace takes a long time after planning
We use Pulumi, and archiving the workspace after planning has no effect on our config, and it takes up to a full minute to finish (either with public or private workers), which makes our process slower.
It would be really nice to have a way to disable that functionality with an env variable or stack config option.
- Workaround
- None right now
- Problem
Log in to comment and vote
Comments3
Natalia Gazda
Jul 16
Hey, thanks for the suggestion. We're archiving this one for now. It hasn't picked up much interest since it went up, so it isn't on our near-term roadmap. Archiving isn't deleting: the request stays on record, and if it gathers more votes or comments we can bring it back. If it still matters to you, add a vote or a comment so we can gauge the demand.
Black Breeze
Oct 12, 2025
Hey! Before we jump into solutions, I’d like to understand this a bit more.
Based on my understanding, there’s still a handful of reasons why it makes sense to archive the workspace for Pulumi.
1. Provider binaries: Just like Terraform, Pulumi needs to download provider plugins (for AWS, Azure, GCP, etc.). These can be substantial in size and take time to download. If you archive the workspace after preview, you don't need to re-download them for the apply phase.
2. Local files generated during preview: If the Pulumi program generates any local files, configurations, or intermediate artifacts during the preview that are needed for the update, those need to be preserved.
3. Node modules / dependencies: For Pulumi programs written in TypeScript/JavaScript, Python, Go, etc., the installed dependencies need to be available for the apply phase. Re-installing these could be time-consuming.
4. Consistency: Even though Pulumi's state is managed externally (in backends like Pulumi Cloud, S3, etc.), having the exact same workspace environment ensures consistency between preview and update.
Technically speaking instead of adding an escape hatch with an environment variable, you could prune the workspace that’s being archived. But again, let’s please first try to understand what exactly we’re trying to achieve and what we’re optimizing for.
Maroon Spacewalk
Oct 16, 2025
Provider binaries and Node modules / dependencies:
in our private workers, the installation phase lasts 7 seconds, to install every python package we need and also plugins. Archiving takes substantially more than that.
Local files generated during preview:
Pulumi doesn’t generate anything of this sort. When running the apply phase, everything is planned again (I know, it sucks). The plan file feature is still in beta.
Consistency:
Like I said, there’s nothing that pulumi gets from running a plan, just an output useful for our analysis.
On top of all this, I did try not installing dependencies again after planning, and it didn’t work, I could try again and see if we can troubleshoot the problem, but knowing that it takes 7 seconds to install everything with uv, it’s not worth it.