Host Your Own Terraform Providers in Scalr

If you've ever maintained an internal fork of a public provider, written a provider for an in-house system, or needed a paper trail of who published what binary and when, the new private provider registry in Scalr is for you.

What It Does

The private provider registry lets you host Terraform and OpenTofu provider binaries directly in your Scalr account. Consumers reference them with the same required_providers syntax they already use for the public registry, the only difference is the source address points at your Scalr host.

terraform {
  required_providers {
    acme = {
      source  = "<account>.scalr.io/providers/acme"
      version = ">= 1.0.0"
    }
  }
}

No custom CLI flags. No extra plugins. Any Terraform or OpenTofu version that speaks the standard registry protocol resolves and downloads from Scalr automatically.

The Problems It Solves

Internal and forked providers. The public Terraform registry isn't the right home for proprietary providers or patched forks. Until now, teams worked around this with direct binary downloads, local mirrors, or custom terraform init scripts all of which are fragile and hard to govern. The private registry gives these providers a proper home with versioning, access control, and usage reporting built in.

Supply chain control. Every provider version in the registry is signed with a GPG key you manage. Scalr stores the public half, verifies the detached signature against the SHA256SUMS file on upload, and rejects anything that doesn't match. You control what gets in.

Least-privilege access. Publisher and consumer permissions are separate. A release automation service account can hold provider-versions:create without touching GPG key management or deleting providers. Workspace runs only need providers:read and the download URL Scalr hands back to the CLI is short-lived and scoped to that permission, so stale links can't be reused.

How Publishing Works

Publishing is a two-step flow designed to fit into a CI pipeline:

1. Create the version record — POST to the API with the provider ID, semver string, and GPG key reference. Scalr returns an upload URL.
2. Upload the release tarball — Build binaries for the platforms you care about, generate a SHA256SUMS file, sign it with GPG, bundle everything into a tar.gz, and PUT it to the URL from step 1. Scalr unpacks, verifies, and marks the version uploaded.

The UI surfaces the exact commands to run for each step, so one-off releases don't require writing API calls by hand.

Supported platforms cover the full range you'd expect: linux, darwin, and windows across amd64, arm64, 386, and arm. Ship only the combinations your infrastructure actually uses.

Visibility After the Fact

Private provider usage flows into Scalr's existing reports feature. You can see which workspaces are on which version, track adoption of a new release, and make a clean deprecation decision when it's time to retire an old one — all without digging through run logs.

Getting Started

You need three things before your first publish:

• A GPG signing key (upload the public half under Registry → GPG Keys)
• A provider record (Registry → Providers → New provider)
• A provider version and its tarball

From there, any workspace in your account can consume the provider with nothing beyond providers:read, the same permission a workspace already needs to read most account-level resources.

Full setup documentation is at docs.scalr.io.