Skip to main content

Default worker image for Terraform modules

Feature RequestsTerraform registrySpacelift Provider

Spacelift allows setting “Default runner image” for public and private runners. To my understanding, this affects only image for Stacks, not Terraform Modules, which still require setting custom image individually.

It would be nice to for this option to affect Terraform modules runner image as well, or there could be a separate setting for just TF modules to offer more flexibility (This would be a separate Spacelift Terraform provider resource as well…).

Workaround
Problem
Status: ✅ Completed4 comments

Log in to comment and vote

Comments4

  • Jonah Kowall

    Team•

    Sep 25

    Good callout on this one and you've hit an inconsistency here, and it's a fair thing to expect us to close. The account-level default runner image applies to stacks but not to Terraform modules, so modules have to be configured individually. Modules already mirror stacks across most configuration surfaces (contexts, environment, policies, runtime config), so the default runner image being an exception is an asymmetry rather than a deliberate design choice. We agree modules should honor the account default the same way stacks do, and we've routed this to the team that owns runner image handling to close the gap.

    In the meantime, two ways to get centralized, version-controlled image management today:

    1. Runtime configuration file: add a .spacelift/config.yml to your module repositories with a runner_image entry. The image version then lives in version control alongside the module, with review and history on changes. This works for module repos, not just stacks.

    2. Manage it as code: since modules are manageable via the spacelift_module Terraform resource, you can set runner_image from a single shared local or variable across every module, so a version bump becomes a one-line change applied to all of them. This is close to your current workaround but removes the per-module duplication.

    Either gives you control now.

    One thing that would help us size it: roughly how many modules are you managing, and how often does the image version actually change for you?

    • Rose Beaver

      •

      Nov 4

      We are just getting started with TF modules so currently are < 10 here.

      The Spacelift worker update is again something we are looking to do much more frequently, so we are trying to remove all the road blocks along the way. Right now, it is let’s say once a month.

      • Jonah Kowall

        Team•

        Nov 5

        Hi Ivo, I need to correct my earlier reply: this already works. In January we changed modules so they fall back to the account default runner image the same way stacks do. The order is .spacelift/config.yml, then the module's own runner image setting, then the account default under Organization Settings > Runtime Security. That holds whether the module is created in the UI or through the spacelift_module resource.

        For your modules, remove runner_image from each one (and from any .spacelift/config.yml) and set the account default for the worker pool type you use. Public and private pools have separate defaults. After that, your monthly worker update is one change in Runtime Security instead of one per module. If a module run still picks up Spacelift's stock image after that, send me the run link and we'll dig in.

        Our docs still describe the account default as stacks-only, which is likely where this came from. We're updating them. I'm marking this one Completed.

        • Rose Beaver

          •

          Nov 6

          Thanks, will check! Just a note: we are on Spacelift self-hosted, not sure if our current version supports it. I will test it when I get the opportunity.

  • Linked to Module tests should use default image from module or organisational settings