fix: persist Pulumi plugin cache across container runs

[alexjurkiewicz]

Summary

• Sets PULUMI_HOME to ~/.cloudypad/pulumi-home in cloudypad.sh so Pulumi's plugin cache (provider binaries) is stored inside the already-mounted ~/.cloudypad directory
• Without this, plugins like pulumi-resource-aws are re-downloaded on every container invocation

Details

~/.pulumi/plugins contains provider binaries that Pulumi downloads at runtime. This directory was not bind-mounted, so plugins were re-downloaded on every container run (adding ~30–60s to every command).

Rather than mounting a separate ~/.pulumi directory (which would require users to have Pulumi installed locally), PULUMI_HOME is redirected to ~/.cloudypad/pulumi-home, which is already bind-mounted. This keeps all CloudyPad runtime state in one place.

Note: ~/.cloudypad/pulumi-backend/.pulumi is the Pulumi state backend (stack checkpoints) and is already persisted. This change addresses only the separate plugin cache.

Test plan

• Run any cloudypad command twice; confirm second run does not re-download provider plugins
• Confirm ~/.cloudypad/pulumi-home/plugins/ is populated after first run

🤖 Generated with Claude Code

[PierreBeucher]

You're hitting a spot I intended to work on for some time - however instead of persistent plugins locally I had in mind to bake them directly into the image from Dockerfile, by adding commands pulumi plugin install directly there. It would help with reproduciblity and would even prevent any Pulumi plugin download at runtime (using https://www.pulumi.com/docs/iac/cli/commands/pulumi_plugin_install/)

Do you think it's possible ?

[alexjurkiewicz]

It sounds possible. The AWS plugin is 700mb -- if you upx it, it's over 100mb.

The runner is currently about 3gb. Another 700mb is quite a lot to swallow. It's up to you.

[PierreBeucher]

Fair point ^^' resulting image may be too big. I'll do a quick test to check, but your solution seems the right fit!

[alexjurkiewicz]

Pulumi has no lockfile, but you can explicitly install a certain provider version and check its hash yourself. That might be sufficient? It's more self-managed infrastructure tooling though ⚖️