Registry Usage

The Status200 provider is published to the Terraform Registry and the OpenTofu Registry. terraform init and tofu init download it from there: there is nothing to install by hand. This page covers what is published, how versions are numbered, and how to move to a newer one.

What is published#

Every Status200 release generates the provider from Status200's own API. When the provider changed, the release publishes it, under the release's version, once it has passed its end-to-end tests under Terraform and under OpenTofu:

The reference lists what each attribute is. These docs show how to use them together: start from the Terraform Overview.

How versions are numbered#

A provider's version is the version of the Status200 release that published it: provider 14.0.20 came with Status200 14.0.20. A release whose provider did not change publishes none, so the versions have gaps, and a constraint that names one exact version can name a version that does not exist. Write a range instead:

On a self-hosted Status200, a provider newer than your Status200 may send settings your Status200 does not have yet: Self-Hosted Setup shows how to write its range.

terraform {
  required_providers {
    oneuptime = {
      source  = "oneuptime/status200"
      version = "~> 14.0"
    }
  }
}

The source address names no registry: Terraform reads it from the Terraform Registry, and OpenTofu from the OpenTofu Registry, which publish the same versions.

The lock file#

terraform init records the version it picked, and the checksums of its downloads, in .terraform.lock.hcl. Commit that file: every machine and every CI run then installs exactly that version, until you choose another one. The checksums cover every platform the registry publishes, so one lock file serves Linux, macOS and Windows machines alike.

provider "registry.terraform.io/status200/status200" {
  version     = "14.0.20"
  constraints = "~> 14.0"
  hashes = [
    "h1:...",
    "zh:...",
  ]
}

The lock file names the registry. OpenTofu writes registry.opentofu.org/status200/status200 where Terraform writes registry.terraform.io/status200/status200, so switching engines changes the lock file: init replaces the entry, and asks you to commit the change.

Move to a newer version#

1. Read what changed#

   Status200's releases say what each release changed, the provider included. The provider's releases link to the changes since the one before.

2. Download it#

   Bash

   terraform init -upgrade

   init -upgrade takes the newest version your constraint allows, prints it, and updates .terraform.lock.hcl. The constraint ~> 14.0 takes every 14.x release; a new major version needs a new constraint.

3. Plan before you apply#

   Run terraform plan, and apply only when it is empty or shows the changes you expect. Commit the updated lock file.

On a self-hosted Status200, upgrade Status200 first, then raise the end of the provider's range.

Where the code lives#

The provider is generated from the Status200 API in the main Status200 repository, and each version is built from the release that published it. Its own repository, OneUptime/terraform-provider-status200, holds what the generator wrote, so changes are made in the main repository: report problems, documentation ones included, at git.wilix.dev/status200/status200/issues.

Next steps#