Constraints and the Lock File

Scenario: Two engineers run the same configuration and select different provider releases, producing different plans.

A version constraint defines acceptable versions; the dependency lock file records the exact selected provider version and checksums. ~> 1.4 permits compatible 1.x releases from 1.4 upward but not 2.0, while >= alone may allow breaking majors. Commit .terraform.lock.hcl; update intentionally with init -upgrade, then review and test. Terraform's required_version constrains the CLI separately.

Analogy: Constraints are the restaurant's acceptable ingredients; the lock file is the exact supplier batch used for today's service.

A worked configuration

terraform {
  required_version = ">= 1.8, < 2.0"
  required_providers {
    fakecloud = {
      source  = "shellgenius/fakecloud"
      version = "~> 1.0"
    }
  }
}

Mirrors and checksum verification matter in restricted environments. Lock entries are platform-aware; teams targeting multiple architectures may need to populate checksums deliberately. Do not delete the lock file merely to silence an installation problem.

Note: Treat the plan as a change contract: understand every create, update, replacement, and destroy before approving it.

Goal: Reinforce this lesson in the tf-version-lockfile Terraform lab. Open /labs/terraform and choose slug tf-version-lockfile; the lab runs real Terraform against the offline FakeCloud provider.