# Registry Usage

The Status200 provider is published to the [Terraform Registry](https://registry.terraform.io/providers/status200/status200) and the [OpenTofu Registry](https://search.opentofu.org/provider/status200/status200/latest). `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.

:::cards
- [What is published](#what-is-published): The provider for each platform, its reference, and its versions.
- [How versions are numbered](#how-versions-are-numbered): A provider's version is the Status200 release that published it.
- [The lock file](#the-lock-file): The version and checksums every machine installs.
- [Move to a newer version](#move-to-a-newer-version): Read what changed, download it, and plan.
:::

## 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:

```mermaid title="From a Status200 release to your terraform init"
flowchart TB
    R["A Status200 release"] --> G["The provider is generated<br/>from Status200's API"]
    G --> C{"Did the provider<br/>change?"}
    C -->|"yes"| P["Tested under Terraform<br/>and OpenTofu, then<br/>published with the<br/>release's version"]
    C -->|"no"| N["No provider version<br/>for this release"]
    P --> I["terraform init<br/>and tofu init<br/>download it"]
```

| What | Where |
| --- | --- |
| The provider, for Linux, macOS, Windows, FreeBSD, OpenBSD and Solaris | Downloaded by `terraform init` and `tofu init`, with checksums that Status200 signs |
| The reference of every resource and data source, with each of its attributes | The registry's documentation, grouped by product: monitors, status pages, incidents, on-call and the others |
| A guide to using the provider with OpenTofu | The registry's guides |
| Every version, newest first | The registry's version list |

The reference lists what each attribute is. These docs show how to use them together: start from the [Terraform Overview](/docs/terraform/index).

## 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:

| You use | Constraint | Terraform installs |
| --- | --- | --- |
| Status200 Cloud | `~> 14.0` | The newest 14.x provider |
| A self-hosted Status200 | A range that ends at your Status200's version, such as `>= 14.0, <= 14.0.40` | The newest provider that is not newer than your Status200 |

On a self-hosted Status200, a provider newer than your Status200 may send settings your Status200 does not have yet: [Self-Hosted Setup](/docs/terraform/self-hosted#pick-the-provider-version) shows how to write its range.

```hcl title="main.tf"
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.

```hcl title=".terraform.lock.hcl"
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

:::steps
### Read what changed

[Status200's releases](https://git.wilix.dev/status200/status200/releases) say what each release changed, the provider included. [The provider's releases](https://github.com/OneUptime/terraform-provider-status200/releases) link to the changes since the one before.

### 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.

### 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](https://git.wilix.dev/status200/status200), and each version is built from the release that published it. Its own repository, [OneUptime/terraform-provider-status200](https://github.com/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](https://git.wilix.dev/status200/status200/issues).

## Next steps

:::cards
- [Self-Hosted Setup](/docs/terraform/self-hosted): The version range for your own Status200, and a mirror for offline machines.
- [OpenTofu](/docs/terraform/opentofu): The same provider and configuration, with `tofu`.
- [Complete Guide](/docs/terraform/complete-guide): Authentication, project layout, data sources, state and upgrades.
- [Troubleshooting](/docs/terraform/troubleshooting): Common errors and how to fix them.
:::