Skip to main content

Support Building Docker Images with Spacelift Workerpool on EC2

Feature RequestsWorkersStacksIntegrations

We would like the ability to build Docker images within Spacelift jobs using the Docker Terraform provider while running on the EC2-based worker pool module. Currently, this is not possible due to the lack of Docker daemon access within the job containers.

Problem
Status: ❌ Rejected7 comments

Log in to comment and vote

Comments7

  • Black Breeze

    •

    Jun 6, 2025

    Jeff, coming to think of it a bit more… perhaps a tool like Buildah or Kaniko would do the trick? These allow you to build and push images without the Docker daemon.

    Either way, I will be closing this particular request as not something we’d like to support.

  • Copper Eraser

    •

    May 14, 2025

    After discussing internally, biting the bullet and doing a two stage build is probably the right call for us. Thanks for talking this through.

  • Copper Eraser

    •

    May 14, 2025

    Yeah, I’m totally with you on “Is Spacelift the right layer?” That’s more or less the initial ask here, and maybe the answer is “no”.

    I don’t fully understand what you mean by “Could we document or template that pattern,” in this context, so I’d be curious to know more about that.

    • Black Breeze

      •

      May 14, 2025

      Sure thing! Imagine a hypothetical OpenTofu/Terraform resource that would start a job on some external CI/CD system - for example CodeBuild - wait until it completes, and return a produced artifact. Like so (pseudo-Tofu):

      resource "ci_build" "myimage" {
  // takes build instructions, polls for completion
}

resource "image_consumer" "myconsumer" {
  docker_image = ci_build.myimage.image_uri
}

  • Black Breeze

    •

    May 14, 2025

    Thanks for the request—totally hear the desire to build and push Docker images inline during a Terraform run. That’s about collapsing a two-phase workflow into one for convenience.

    But enabling privileged mode introduces major risks:

    • Secrets and artifacts may persist across runs or users on the same worker.

    • Host-level access breaks containment—users could leave behind containers, processes, or even malware.

    • It undermines the guarantees we count on for safe, predictable execution.

    So we’re asking:

    • Is Spacelift the right layer to solve this?

    • Would pushing the build to something like CodeBuild, triggered from Terraform, get you the one-phase flow without compromising worker security?

    • Could we document or template that pattern instead of turning on a dangerous global switch?

    We want to help you get the job done—but also keep Spacelift safe and composable. Privileged mode might not be the best bet.

  • Copper Eraser

    •

    May 13, 2025

    We’re hoping to continue using this provider to build images within our HCL, rather than having to refactor into a two-step build process. An example use case is building lambdas that live totally in IaC. Check in a little python, add a docker provider, and you can one-shot a full lambda all within HCL.

    https://github.com/kreuzwerker/terraform-provider-docker

  • Black Breeze

    •

    May 10, 2025

    Thanks for the suggestion!

    Just to clarify—Spacelift isn’t a general-purpose CI/CD system, and we don’t aim to be. We focus on orchestrating infrastructure, not building Docker images.

    That said, we do support Docker image workflows as part of infra delivery, via our external dependencies mechanism. This lets an external system (like a CI job or registry) handle the image build, and notify Spacelift when it’s ready—before any infrastructure runs that depend on it.

    If that model doesn’t work for your use case, we’d love to understand why. What’s the broader job you’re trying to do—and where does it get hard today?