Skip to main content

Worker launcher should allow to set another default docker image

Feature Requests

Currently, if no .spacelift/config.yml file is provided at the repository root, the launcher defaults to the Spacelift image public.ecr.aws/spacelift/runner-terraform:latest, and there’s no way to change that default for all stacks/runs.

However, to not force a .spacelift/config.yml file on each repository, and at the same time provide a way for customers to have their own default image for all the runs in a workerpool, the launcher should allow to customize that default image via environment variable (e.g. SPACELIFT_LAUNCHER_DEFAULT_RUNNER_IMAGE)

Workaround
N/A
Status: ✅ Completed18 comments

Log in to comment and vote

Comments18

  • Black Breeze

    •

    May 9, 2025

    Pinned

    Thanks for laying this out—we hear the pain.

    You’re not the first to hit friction when scaling config across stacks—whether it’s Docker images, tags, env vars, or other runtime settings. It’s clear there’s a deeper pattern here: teams want to avoid tedious, error-prone repetition when they grow.

    But changing how defaults work—especially across layers like worker pools, spaces, and stacks—has real complexity. It affects clarity, overrides, and how predictable the platform feels.

    So we’re going to pause here and take a few weeks to look at the broader picture: what good config reuse should look like across Spacelift. We don’t want to bolt something on just because it solves one edge—we want to solve the class of problem properly.

    If others are running into similar scaling headaches, now’s a good time to chime in:

    • What kinds of config are you repeating?

    • What are you trying to avoid?

    • Where would you expect to define shared defaults?

    Thanks again for pushing—this is the kind of feedback that shapes the product, even if we don’t always ship it straight away.

  • Rose Newt

    •

    May 14, 2025

    Just to add my 2p in here, this seems like something we want as well. We essentially want to detach from using spacelift’s default latest image, and mandate use of an internally managed image by default on our workers that are kubernetes hosted. We can see configuration options for init and launcher, but not worker, and as I believe, this is where our users would need custom tools installed.

    We’re setting up as having an internally approved build image in devops attached to build agents, and users consume those build agents. We want to repeat this in Spacelift, maintaining a central image for our users to use with custom tooling.

  • Black Breeze

    •

    Jun 6, 2025

    We're planning to implement this as an Enterprise account-level setting for secure defaults.

    Approach: Global fallback that only applies when no image is explicitly set via stack config or .spacelift/config.yml. This eliminates the compliance toil of having to configure every repo while maintaining security control.

    Why Enterprise + Account-level: Ensures consistent security posture across all stacks regardless of space/worker pool movement, while making it a value-add for compliance-focused organizations.

    • Rose Newt

      •

      Jun 17, 2025

      Lovely stuff! Can’t wait thanks guys :)

  • Aquamarine Savanna

    •

    Mar 21, 2025

    The main idea is to be able to configure that image per launcher/workerpool, in addition to the currently possible ability to configure it by repository/stack. At the end this will introduce another default level (stack config → repo default → workerpool default → Spacelift default), where workerpool default is the new addition.

  • Black Breeze

    •

    May 8, 2025

    Thanks for the thoughtful suggestion! We’d love to understand the deeper need here.

    You mentioned wanting to avoid requiring a .spacelift/config.yml in every repo just to set a default image—and instead, define that default at a broader level like the worker launcher. That makes sense on the surface, but we’re curious:

    • What’s the core problem you’re trying to solve?

      Is it about reducing repo boilerplate, ensuring consistency, simplifying onboarding, or something else?

    • When does this become painful today?

      Are there dozens of stacks missing the config file, or is this a standard you want to enforce org-wide?

    • Why set it via env var?

      That approach seems static—you’d need to restart the launcher to change it. More dangerously, you could end up with a mix of launchers using the new and the old default image! Would setting the default on the worker pool level (where you already manage behavior) give you more flexibility?

    • What does success look like?

      Is it “never having to set the image per stack again,” “being able to hot-swap the image across all stacks,” or “ensuring certain repos use only trusted base images”?

    We want to make sure we’re solving the right problem—not just building a clever workaround.

    Let us know more about your setup and the friction you’re trying to remove!