Skip to main content

Feature Request: Native Spacelift Provider Mirror & Transparent Cache

Feature RequestsTerraform registrySelf-hostedStack DependenciesOpenTofuWorkers

Spacelift should provide a native, managed way to mirror or cache OpenTofu and Terraform providers to ensure build reliability and performance. Currently, every Spacelift run is directly dependent on the availability and speed of public registries (like registry.opentofu.org).

We are requesting a Spacelift-native solution that can be implemented in one of two ways:

  1. Transparent Pull-Through Cache: A managed proxy where Spacelift automatically caches requested provider binaries. If a worker requests a provider version, Spacelift fetches it once from the upstream registry and serves it for all subsequent runs.

  2. Managed OCI/ORAS Mirror: A built-in registry where Spacelift hosts provider artifacts. This could be implemented as a ORAS (OCI Registry As Storage) project standards, allowing users to leverage OCI-native provider distribution (OpenTofu 1.8+) without having to manage their own external OCI infrastructure or complex manifest logic.

How this helps Spacelift

This feature would position Spacelift as the "Source of Truth" for the entire execution environment. By leveraging the ORAS standard natively, Spacelift would stay ahead of the curve as the ecosystem shifts toward OCI-based provider distribution, saving customers from the "undifferentiated heavy lifting" of building their own mirrors.

Workaround
Problem
Status: ❌ Rejected4 comments

Log in to comment and vote

Comments4

  • Black Breeze

    •

    Feb 11

    Thanks for the detailed feature request, Rocky.

    We understand the frustration when upstream registries go down — the recent OpenTofu registry outage caused by a GitHub incident is a good example. That said, after careful consideration, we've decided not to pursue this at this time.

    Spacelift, by its very nature, operates in a distributed environment where external dependencies — cloud providers, registries, APIs — are always in some state of partial disrepair. That's the reality of distributed systems. In this particular case, the OpenTofu registry's dependency on GitHub is something the OpenTofu project can take steps to reduce if these outages continue to be a problem.

    Replicating a significant portion of the public registry infrastructure to insulate Spacelift runs from upstream issues doesn't feel like the right tradeoff yet, especially when the resources Spacelift manages (cloud infrastructure, APIs, etc.) are themselves subject to the same kind of flakiness. If your provider registry is down at the same time as the infrastructure you're trying to manage, caching the providers locally doesn't get you very far.

    That said, we'll keep an eye on this. If the ecosystem's reliability picture changes or OCI-based distribution matures to a point where this becomes a lighter lift, we're open to revisiting it.