Remove Terraform mentions in docs in the codebase (#713)

CHANGELOG.md

@@ -25,7 +25,7 @@ NEW FEATURES:
 
 ENHANCEMENTS:
 
-* config: OpenTofu can now track some additional detail about values that won't be known until the apply step, such as the range of possible lengths for a collection or whether an unknown value can possibly be null. When this information is available, Terraform can potentially generate known results for some operations on unknown values. This doesn't mean that Terraform can immediately track that detail in all cases, but the type system now contains the facility for that and so over time we will improve the level of detail generated by built-in functions, language operators, Terraform providers, etc. ([#33234](https://github.com/hashicorp/terraform/issues/33234))
+* config: OpenTofu can now track some additional detail about values that won't be known until the apply step, such as the range of possible lengths for a collection or whether an unknown value can possibly be null. When this information is available, OpenTofu can potentially generate known results for some operations on unknown values. This doesn't mean that OpenTofu can immediately track that detail in all cases, but the type system now contains the facility for that and so over time we will improve the level of detail generated by built-in functions, language operators, OpenTofu providers, etc. ([#33234](https://github.com/hashicorp/terraform/issues/33234))
 * jsonplan: Added `errored` field to JSON plan output, indicating whether a plan errored. ([#33372](https://github.com/hashicorp/terraform/issues/33372))
 * cloud: Remote plans on cloud backends can now be saved using the `-out` flag, referenced in the `show` command, and applied by specifying the plan file name. ([#33492](https://github.com/hashicorp/terraform/issues/33492))
 * config: The `import` block `id` field now accepts an expression referencing other values such as resource attributes, as long as the value is a string known at plan time. ([#33618](https://github.com/hashicorp/terraform/issues/33618))

README.md

@@ -8,7 +8,7 @@
 ![](https://raw.githubusercontent.com/opentofu/brand-artifacts/main/full/transparent/SVG/on-dark.svg#gh-dark-mode-only)
 ![](https://raw.githubusercontent.com/opentofu/brand-artifacts/main/full/transparent/SVG/on-light.svg#gh-light-mode-only)
 
-**Important Note: This repository is currently a work in progress while we're preparing it for the first alpha release and fine-tuning the community contribution process. Please read the [announcement post](https://opentofu.org/fork) for important context and the [contributing docs](CONTRIBUTING.md) for instructions on how to contribute. Additionally, please be mindful that building this repository in its current state and running it might put you in violation of the [Terraform Registry ToS](https://web.archive.org/web/https://registry.terraform.io/terms), if that's where you fetch your providers or modules from.**
+**Important Note: This repository is currently a work in progress while we're preparing it for the first stable release and fine-tuning the community contribution process. Please read the [announcement post](https://opentofu.org/fork) for important context and the [contributing docs](CONTRIBUTING.md) for instructions on how to contribute.**
 
 OpenTofu is an OSS tool for building, changing, and versioning infrastructure safely and efficiently. OpenTofu can manage existing and popular service providers as well as custom in-house solutions.
 

docs/architecture.md

@@ -63,8 +63,7 @@ constructed, and then the backend is responsible for executing that action.
 
 Backends that execute operations, however, do so as an architectural implementation detail and not a
 general feature of backends. That is, the term 'backend' as a OpenTofu feature is used to refer to
-a plugin that determines where OpenTofu stores its state snapshots - only the default `local`
-backend and Terraform Cloud's backends (`remote`, `cloud`) perform operations.
+a plugin that determines where OpenTofu stores its state snapshots - only the default `local`, `remote` and `cloud` backends perform operations.
 
 Thus, most backends do _not_ implement this interface, and so the `command` package wraps these
 backends in an instance of
@@ -85,7 +84,7 @@ specified in the operation, then uses the _config loader_ to load and do
 initial processing/validation of the configuration specified in the
 operation. It then uses these, along with the other settings given in the
 operation, to construct a
-[`terraform.Context`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#Context),
+[`tofu.Context`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#Context),
 which is the main object that actually performs OpenTofu operations.
 
 The `local` backend finally calls an appropriate method on that context to
@@ -160,7 +159,7 @@ kind of arbitrary blob store.
 ## Graph Builder
 
 A _graph builder_ is called by a
-[`terraform.Context`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#Context)
+[`tofu.Context`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#Context)
 method (e.g. `Plan` or `Apply`) to produce the graph that will be used
 to represent the necessary steps for that operation and the dependency
 relationships between them.
@@ -187,7 +186,7 @@ graph from the set of changes described in the plan that is being applied.
 
 The graph builders all work in terms of a sequence of _transforms_, which
 are implementations of
-[`terraform.GraphTransformer`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#GraphTransformer).
+[`tofu.GraphTransformer`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#GraphTransformer).
 Implementations of this interface just take a graph and mutate it in any
 way needed, and so the set of available transforms is quite varied. Some
 important examples include:
@@ -217,7 +216,7 @@ builder uses a different subset of these depending on the needs of the
 operation that is being performed.
 
 The result of graph building is a
-[`terraform.Graph`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#Graph), which
+[`tofu.Graph`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#Graph), which
 can then be processed using a _graph walker_.
 
 ## Graph Walk
@@ -229,15 +228,15 @@ itself is implemented in
 (where "DAG" is short for [_Directed Acyclic Graph_](https://en.wikipedia.org/wiki/Directed_acyclic_graph)), in
 [`AcyclicGraph.Walk`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/dag#AcyclicGraph.Walk).
 However, the "interesting" OpenTofu walk functionality is implemented in
-[`terraform.ContextGraphWalker`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#ContextGraphWalker),
+[`tofu.ContextGraphWalker`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#ContextGraphWalker),
 which implements a small set of higher-level operations that are performed
 during the graph walk:
 
 * `EnterPath` is called once for each module in the configuration, taking a
   module address and returning a
-  [`terraform.EvalContext`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#EvalContext)
-  that tracks objects within that module. `terraform.Context` is the _global_
-  context for the entire operation, while `terraform.EvalContext` is a
+  [`tofu.EvalContext`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#EvalContext)
+  that tracks objects within that module. `tofu.Context` is the _global_
+  context for the entire operation, while `tofu.EvalContext` is a
   context for processing within a single module, and is the primary means
   by which the namespaces in each module are kept separate.
 
@@ -280,19 +279,19 @@ a plan operation would include the following high-level steps:
   this operation.
 
 Each execution step for a vertex is an implementation of
-[`terraform.Execute`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/erraform#Execute).
+[`tofu.Execute`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/erraform#Execute).
 As with graph transforms, the behavior of these implementations varies widely:
 whereas graph transforms can take any action against the graph, an `Execute`
 implementation can take any action against the `EvalContext`.
 
-The implementation of `terraform.EvalContext` used in real processing
+The implementation of `tofu.EvalContext` used in real processing
 (as opposed to testing) is
-[`terraform.BuiltinEvalContext`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#BuiltinEvalContext).
+[`tofu.BuiltinEvalContext`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#BuiltinEvalContext).
 It provides coordinated access to plugins, the current state, and the current
 plan via the `EvalContext` interface methods.
 
 In order to be executed, a vertex must implement
-[`terraform.GraphNodeExecutable`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#GraphNodeExecutable),
+[`tofu.GraphNodeExecutable`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#GraphNodeExecutable),
 which has a single `Execute` method that handles. There are numerous `Execute`
 implementations with different behaviors, but some prominent examples are:
 
@@ -367,7 +366,7 @@ known when the main graph is constructed, but become known while evaluating
 other vertices in the main graph.
 
 This special behavior applies to vertex objects that implement
-[`terraform.GraphNodeDynamicExpandable`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#GraphNodeDynamicExpandable).
+[`tofu.GraphNodeDynamicExpandable`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#GraphNodeDynamicExpandable).
 Such vertices have their own nested _graph builder_, _graph walk_,
 and _vertex evaluation_ steps, with the same behaviors as described in these
 sections for the main graph. The difference is in which graph transforms

internal/ipaddr/README.md

@@ -23,9 +23,8 @@ After careful consideration, it was concluded that OpenTofu's
 use of these functions as part of the implementation of the `cidrhost`,
 `cidrsubnet`, `cidrsubnets`, and `cidrnetmask` functions has a more limited
 impact than the general availability of these functions in the Go standard
-library, and so we can't justify a similar exception to our Terraform 1.0
-compatibility promises as the Go team made to their Go 1.0 compatibility
-promises.
+library, and so we can't justify a similar exception to our compatibility
+promises as the Go team made to their Go 1.0 compatibility promises.
 
 If you're considering using this package for new functionality _other than_ the
 built-in functions mentioned above, please do so only if consistency with the

website/docs/cli/commands/init.mdx

@@ -120,7 +120,7 @@ During init, OpenTofu searches the configuration for both direct and indirect
 references to providers and attempts to install the plugins for those providers.
 
 For providers that are published in either
-[the public Terraform Registry](https://registry.terraform.io/) or in a
+[the public OpenTofu Registry](https://registry.opentofu.org/) or in a
 third-party provider registry, `tofu init` will automatically find,
 download, and install the necessary provider plugins. If you cannot or do not
 wish to install providers from their origin registries, you can customize how

website/docs/cli/config/config-file.mdx

@@ -148,9 +148,9 @@ If neither are set, any configured credentials helper will be consulted.
 
 The default way to install provider plugins is from a provider registry. The
 origin registry for a provider is encoded in the provider's source address,
-like `registry.terraform.io/hashicorp/aws`. For convenience in the common case,
+like `registry.opentofu.org/hashicorp/aws`. For convenience in the common case,
 OpenTofu allows omitting the hostname portion for providers on
-`registry.terraform.io`, so you can write shorter public provider addresses like
+`registry.opentofu.org`, so you can write shorter public provider addresses like
 `hashicorp/aws`.
 
 Downloading a plugin directly from its origin registry is not always
@@ -192,16 +192,16 @@ providers can be installed only directly from their origin registries.
 
 If you set both `include` and `exclude` for a particular installation
 method, the exclusion patterns take priority. For example, including
-`registry.terraform.io/hashicorp/*` but also excluding
-`registry.terraform.io/hashicorp/dns` will make that installation method apply
+`registry.opentofu.org/hashicorp/*` but also excluding
+`registry.opentofu.org/hashicorp/dns` will make that installation method apply
 to everything in the `hashicorp` namespace with the exception of
 `hashicorp/dns`.
 
 As with provider source addresses in the main configuration, you can omit
-the `registry.terraform.io/` prefix for providers distributed through the
-public Terraform registry, even when using wildcards. For example,
-`registry.terraform.io/hashicorp/*` and `hashicorp/*` are equivalent.
-`*/*` is a shorthand for `registry.terraform.io/*/*`, not for
+the `registry.opentofu.org/` prefix for providers distributed through the
+public OpenTofu Registry, even when using wildcards. For example,
+`registry.opentofu.org/hashicorp/*` and `hashicorp/*` are equivalent.
+`*/*` is a shorthand for `registry.opentofu.org/*/*`, not for
 `*/*/*`.
 
 The following are the two supported installation method types:

website/docs/internals/json-format.mdx

@@ -371,7 +371,7 @@ Because the configuration models are produced at a stage prior to expression eva
       "name": "aws",
 
       // "full_name" is the fully-qualified provider name
-      "full_name": "registry.terraform.io/hashicorp/aws",
+      "full_name": "registry.opentofu.org/hashicorp/aws",
 
       // "alias" is the alias set for a non-default configuration, or unset for
       // a default configuration.

website/docs/internals/module-registry-protocol.mdx

@@ -12,12 +12,12 @@ about modules available for installation and to locate the distribution
 package for a selected module.
 
 The primary implementation of this protocol is the public
-[Terraform Registry](https://registry.terraform.io/) at `registry.terraform.io`.
+[OpenTofu Registry](https://registry.opentofu.org/) at `registry.opentofu.org`.
 By writing and deploying your own implementation of this protocol, you can
 create a separate registry to distribute your own modules, as an alternative to
-publishing them on the public Terraform Registry.
+publishing them on the public OpenTofu Registry.
 
-The public Terraform Registry implements a superset of the API described on
+The public OpenTofu Registry implements a superset of the API described on
 this page, in order to capture additional information used in the registry UI.
 For information on those extensions, see
 [OpenTofu Registry HTTP API](/docs/registry/api-docs). Third-party registry
@@ -32,7 +32,7 @@ syntax `hostname/namespace/name/system`, where:
 - `hostname` is the hostname of the module registry that serves this module.
 - `namespace` is the name of a namespace, unique on a particular hostname, that
   can contain one or more modules that are somehow related. On the public
-  Terraform Registry the "namespace" represents the organization that is
+  OpenTofu Registry the "namespace" represents the organization that is
   packaging and distributing the module.
 - `name` is the module name, which generally names the abstraction that the
   module is intending to create.
@@ -40,27 +40,27 @@ syntax `hostname/namespace/name/system`, where:
   to target. For multi-cloud abstractions, there can be multiple modules with
   addresses that differ only in "system" to reflect provider-specific
   implementations of the abstraction, like
-  `registry.terraform.io/hashicorp/consul/aws` vs.
-  `registry.terraform.io/hashicorp/consul/azurerm`. The system name commonly
+  `registry.opentofu.org/hashicorp/consul/aws` vs.
+  `registry.opentofu.org/hashicorp/consul/azurerm`. The system name commonly
   matches the type portion of the address of an official provider, like `aws`
   or `azurerm` in the above examples, but that is not required and so you can
   use whichever system keywords make sense for the organization of your
   particular registry.
 
 The `hostname/` portion of a module address (including its slash delimiter)
-is optional, and if omitted defaults to `registry.terraform.io/`.
+is optional, and if omitted defaults to `registry.opentofu.org/`.
 
 For example:
 
 - `hashicorp/consul/aws` is a shorthand for
-  `registry.terraform.io/hashicorp/consul/aws`, which is a module on the
+  `registry.opentofu.org/hashicorp/consul/aws`, which is a module on the
   public registry for deploying Consul clusters in Amazon Web Services.
 - `example.com/awesomecorp/consul/happycloud` is a hypothetical module published
   on a third-party registry.
 
 If you intend to share a module you've developed for use by all OpenTofu
 users, please consider publishing it into the public
-[Terraform Registry](https://registry.terraform.io/) to make your module more
+[OpenTofu Registry](https://registry.opentofu.org/) to make your module more
 discoverable. You only need to implement this module registry protocol if you
 wish to publish modules whose addresses include a different hostname that is
 under your control.

website/docs/internals/provider-network-mirror-protocol.mdx

@@ -39,7 +39,7 @@ from. However, when you configure OpenTofu to install providers from a network
 mirror, the `hostname` serves _only_ as an identifier and no longer as
 an installation source. A provider mirror can therefore serve providers
 belonging to a variety of different provider registry hostnames, including
-providers from the public Terraform Registry at `registry.terraform.io`, from a
+providers from the public OpenTofu Registry at `registry.opentofu.org`, from a
 single server.
 
 In the relative URL patterns later in this document, the placeholder `:hostname`
@@ -227,7 +227,7 @@ the following properties:
   filename would cause OpenTofu to construct a URL like:
 
   ```
-  https://tofu.example.com/providers/registry.terraform.io/hashicorp/random/terraform-provider-random_2.0.0_darwin_amd64.zip
+  https://tofu.example.com/providers/registry.opentofu.org/hashicorp/random/terraform-provider-random_2.0.0_darwin_amd64.zip
   ```
 
 * `hashes` (optional): a JSON array of strings containing one or more hash

website/docs/internals/provider-registry-protocol.mdx

@@ -7,15 +7,15 @@ description: |-
 
 # Provider Registry Protocol
 
-The provider registry protocol is what Terraform CLI uses to discover metadata
+The provider registry protocol is what OpenTofu CLI uses to discover metadata
 about providers available for installation and to locate the distribution
 packages for a selected provider.
 
 The primary implementation of this protocol is the public
-[Terraform Registry](https://registry.terraform.io/) at `registry.terraform.io`.
+[OpenTofu Registry](https://registry.opentofu.org/) at `registry.opentofu.org`.
 By writing and deploying your own implementation of this protocol, you can
 create a separate _origin registry_ to distribute your own providers, as an
-alternative to publishing them on the public Terraform Registry.
+alternative to publishing them on the public OpenTofu Registry.
 
 This page describes the provider _registry_ protocol, which is the protocol
 for finding providers available for installation. It _doesn't_ describe the
@@ -35,27 +35,27 @@ where:
   [unless overridden in the CLI configuration](/docs/cli/config/config-file#provider-installation).
 * `namespace` is the name of a namespace, unique on a particular hostname, that
   can contain one or more providers that are somehow related. On the public
-  Terraform Registry the "namespace" represents the organization that is
+  OpenTofu Registry the "namespace" represents the organization that is
   packaging and distributing the provider.
 * `type` is the provider type, like "azurerm", "aws", "google", "dns", etc.
   A provider type is unique within a particular hostname and namespace.
 
 The `hostname/` portion of a provider address (including its slash delimiter)
-is optional, and if omitted defaults to `registry.terraform.io/`.
+is optional, and if omitted defaults to `registry.opentofu.org/`.
 
 For example:
 
-* `hashicorp/aws` is a shorthand for `registry.terraform.io/hashicorp/aws`,
+* `hashicorp/aws` is a shorthand for `registry.opentofu.org/hashicorp/aws`,
   which is the official AWS provider published by HashiCorp.
-* `example/foo` is a shorthand for `registry.terraform.io/example/foo`, which
+* `example/foo` is a shorthand for `registry.opentofu.org/example/foo`, which
   is a hypothetical third-party provider published on the public
-  Terraform Registry.
+  OpenTofu Registry.
 * `example.com/bar/baz` is a hypothetical third-party provider published at a
   third-party provider registry on `example.com`.
 
 If you intend only to share a provider you've developed for use by all
 OpenTofu users, please consider publishing it into the public
-[Terraform Registry](https://registry.terraform.io/), which will make your
+[OpenTofu Registry](https://registry.opentofu.org/), which will make your
 provider discoverable. You only need to implement this provider registry
 protocol if you wish to publish providers whose addresses include a different
 hostname that is under your control.
@@ -199,7 +199,7 @@ with the following properties:
 * `platforms` (recommended): an array of objects describing platforms that have
   packages available for this version.
 
-  Terraform may use this information, when available, to provide hints to
+  OpenTofu may use this information, when available, to provide hints to
   users about upgrading or downgrading their version of a particular provider
   for compatibility with their current platform.
 

website/docs/intro/index.mdx

@@ -28,7 +28,7 @@ The core OpenTofu workflow consists of three stages:
 
 ### Manage any infrastructure
 
-Find providers for many of the platforms and services you already use in the [Public Terraform Registry](https://registry.terraform.io/). You can also [write your own](/docs/plugin). OpenTofu takes an [immutable approach to infrastructure](https://www.hashicorp.com/resources/what-is-mutable-vs-immutable-infrastructure), reducing the complexity of upgrading or modifying your services and infrastructure.
+Find providers for many of the platforms and services you already use in the [Public OpenTofu Registry](https://registry.opentofu.org/). You can also [write your own](/docs/plugin). OpenTofu takes an [immutable approach to infrastructure](https://www.hashicorp.com/resources/what-is-mutable-vs-immutable-infrastructure), reducing the complexity of upgrading or modifying your services and infrastructure.
 
 ### Track your infrastructure
 
@@ -40,7 +40,7 @@ OpenTofu configuration files are declarative, meaning that they describe the end
 
 ### Standardize configurations
 
-OpenTofu supports reusable configuration components called [modules](/docs/language/modules) that define configurable collections of infrastructure, saving time and encouraging best practices. You can use publicly available modules from the Terraform Registry, or write your own.
+OpenTofu supports reusable configuration components called [modules](/docs/language/modules) that define configurable collections of infrastructure, saving time and encouraging best practices. You can use publicly available modules from the OpenTofu Registry, or write your own.
 
 ### Collaborate
 

website/docs/language/expressions/splat.mdx

@@ -1,6 +1,6 @@
 ---
 description: >-
-  Splat expressions concisely represent common operations. In Terraform, they
+  Splat expressions concisely represent common operations. In OpenTofu, they
   also transform single, non-null values into a single-element tuple.
 ---
 

website/docs/language/files/dependency-lock.mdx

@@ -98,7 +98,7 @@ error if none of the checksums match:
 Error: Failed to install provider
 
 Error while installing hashicorp/azurerm v2.1.0: the current package for
-registry.terraform.io/hashicorp/azurerm 2.1.0 doesn't match any of the
+registry.opentofu.org/hashicorp/azurerm 2.1.0 doesn't match any of the
 checksums previously recorded in the dependency lock file.
 ```
 
@@ -167,7 +167,7 @@ block in the dependency lock file.
    ]
  }
 
-+provider "registry.terraform.io/hashicorp/azurerm" {
++provider "registry.opentofu.org/hashicorp/azurerm" {
 +  version     = "2.30.0"
 +  constraints = "~> 2.12"
 +  hashes = [
@@ -187,7 +187,7 @@ block in the dependency lock file.
 +  ]
 +}
 +
- provider "registry.terraform.io/newrelic/newrelic" {
+ provider "registry.opentofu.org/newrelic/newrelic" {
    version     = "2.1.2"
    constraints = "~> 2.1.1"
 ```
@@ -218,7 +218,7 @@ block to reflect that change.
 @@ -7,22 +7,22 @@
  }
 
- provider "registry.terraform.io/hashicorp/azurerm" {
+ provider "registry.opentofu.org/hashicorp/azurerm" {
 -  version     = "2.1.0"
 -  constraints = "~> 2.1.0"
 +  version     = "2.0.0"
@@ -373,7 +373,7 @@ file entry for that provider.
    ]
  }
 
--provider "registry.terraform.io/hashicorp/azurerm" {
+-provider "registry.opentofu.org/hashicorp/azurerm" {
 -  version     = "2.30.0"
 -  constraints = "~> 2.12"
 -  hashes = [
@@ -393,7 +393,7 @@ file entry for that provider.
 -  ]
 -}
 -
- provider "registry.terraform.io/newrelic/newrelic" {
+ provider "registry.opentofu.org/newrelic/newrelic" {
    version     = "2.1.2"
    constraints = "~> 2.1.1"
 ```

website/docs/language/files/index.mdx

@@ -39,7 +39,7 @@ An OpenTofu module can use [module calls](/docs/language/modules) to
 explicitly include other modules into the configuration. These child modules can
 come from local directories (nested in the parent module's directory, or
 anywhere else on disk), or from external sources like the
-[Public Terraform Registry](https://registry.terraform.io).
+[Public OpenTofu Registry](https://registry.opentofu.org).
 
 ## The Root Module
 

website/docs/language/modules/develop/publish.mdx

@@ -6,7 +6,7 @@ description: A module is a container for multiple resources that are used togeth
 
 If you've built a module that you intend to be reused, we recommend
 [publishing the module](/docs/registry/modules/publish) on the
-[Public Terraform Registry](https://registry.terraform.io). This will version
+[Public OpenTofu Registry](https://registry.opentofu.org). This will version
 your module, generate documentation, and more.
 
 Published modules can be easily consumed by OpenTofu, and users can

website/docs/language/modules/sources.mdx

@@ -88,7 +88,7 @@ A module registry is the native way of distributing modules for use
 across multiple configurations, using an OpenTofu-specific protocol that
 has full support for module versioning.
 
-The [Public Terraform Registry](https://registry.terraform.io/) is an index of modules
+The [Public OpenTofu Registry](https://registry.opentofu.org/) is an index of modules
 shared publicly using this protocol. This public registry is the easiest way
 to get started with OpenTofu and find modules created by others in the
 community.

website/docs/language/modules/syntax.mdx

@@ -98,7 +98,7 @@ constraint; if no acceptable versions are installed, it will download the newest
 version that meets the constraint.
 
 Version constraints are supported only for modules installed from a module
-registry, such as the [Public Terraform Registry](https://registry.terraform.io/)
+registry, such as the [Public OpenTofu Registry](https://registry.opentofu.org/)
 or any TACOS (TF Automation and Collaboration Software) private modules registry.
 Other module sources can provide their own versioning mechanisms within the
 source string itself, or might not support versions at all. In particular,

website/docs/language/providers/configuration.mdx

@@ -53,7 +53,7 @@ arguments that are specified directly in the configuration).
 
 A provider's documentation should list which configuration arguments it expects.
 For providers distributed on the
-[Public Terraform Registry](https://registry.terraform.io), versioned documentation is
+[Public OpenTofu Registry](https://registry.opentofu.org), versioned documentation is
 available on each provider's page, via the "Documentation" link in the
 provider's header.
 

website/docs/language/providers/requirements.mdx

@@ -104,7 +104,7 @@ follows:
 
 * **Hostname** (optional): The hostname of the registry that
   distributes the provider. If omitted, this defaults to
-  `registry.terraform.io`.
+  `registry.opentofu.org`.
 
 * **Namespace:** An organizational namespace within the specified registry.
   In most cases this represents the organization that publishes the provider.
@@ -121,8 +121,8 @@ follows:
 
 For example,
 [the official HTTP provider](https://registry.terraform.io/providers/hashicorp/http)
-belongs to the `hashicorp` namespace on `registry.terraform.io`, so its
-source address is `registry.terraform.io/hashicorp/http` or, more commonly, just
+belongs to the `hashicorp` namespace on `registry.opentofu.org`, so its
+source address is `registry.opentofu.org/hashicorp/http` or, more commonly, just
 `hashicorp/http`.
 
 The source address with all three components given explicitly is called the
@@ -130,12 +130,12 @@ provider's _fully-qualified address_. You will see fully-qualified address in
 various outputs, like error messages, but in most cases a simplified display
 version is used. This display version omits the source host when it is the
 public registry, so you may see the shortened version `"hashicorp/random"` instead
-of `"registry.terraform.io/hashicorp/random"`.
+of `"registry.opentofu.org/hashicorp/random"`.
 
 :::note
 If you omit the `source` argument when requiring a provider,
 OpenTofu uses an implied source address of
-`registry.terraform.io/hashicorp/<LOCAL NAME>`.
+`registry.opentofu.org/hashicorp/<LOCAL NAME>`.
 We recommend using explicit source addresses for all providers.
 :::
 

website/docs/language/resources/syntax.mdx

@@ -107,7 +107,7 @@ To browse the publicly available providers and their documentation, see the
 
 :::note
 Provider documentation previously existed as part of OpenTofu's core documentation. Although some provider documentation
-might still be hosted here, the Public Terraform Registry is now the main home for all
+might still be hosted here, the Public OpenTofu Registry is now the main home for all
 public provider docs.
 :::
 

website/docs/language/settings/backends/local.mdx

@@ -1,7 +1,7 @@
 ---
 sidebar_label: local
 description: >-
-  Terraform can store the state remotely, making it easier to version and work
+  OpenTofu can store the state remotely, making it easier to version and work
   with in a team.
 ---
 
@@ -59,14 +59,14 @@ additional arguments:
 * `-state-out=FILENAME` - overrides the state filename when _writing_ new state
   snapshots.
 
-  If you use `-state` without also using `-state-out` then Terraform will
+  If you use `-state` without also using `-state-out` then OpenTofu will
   use the `-state` filename for both `-state` and `-state-out`, which means
-  Terraform will overwrite the input file if it creates a new state snapshot.
+  OpenTofu will overwrite the input file if it creates a new state snapshot.
 * `-backup=FILENAME` - overrides the default filename that the local backend
   would normally choose dynamically to create backup files when it writes new
   state.
 
-  If you use `-state` without also using `-backup` then Terraform will use
+  If you use `-state` without also using `-backup` then OpenTofu will use
   the `-state` filename as a filename prefix for generating a backup filename.
   You can use `-backup=-` (that is, set the filename to just the ASCII
   dash character) to disable the creation of backup files altogether.
@@ -74,15 +74,15 @@ additional arguments:
 These three options are preserved for backward-compatibility with earlier
 workflows that predated the introduction of built-in remote state, where
 users would write wrapper scripts that fetch prior state before running
-Terraform and then save the new state after Terraform exits, in which case
+OpenTofu and then save the new state after OpenTofu exits, in which case
 the three arguments would typically all be paths within a temporary
 directory used just for one operation.
 
 Because these old workflows predate the introduction of the possibility of
 [multiple workspaces](/docs/language/state/workspaces), setting them
-overrides Terraform's usual behavior of selecting a different state filename
+overrides OpenTofu's usual behavior of selecting a different state filename
 based on the selected workspace. If you use all three of these options then
-the selected workspace has no effect on which filenames Terraform will select
+the selected workspace has no effect on which filenames OpenTofu will select
 for state files, and so you'll need to select different filenames yourself if
 you wish to keep workspace state files distinct from one another.
 
@@ -90,7 +90,7 @@ These three options have no effect for configurations that have a different
 backend type selected.
 
 We do not recommend using these options in new systems, even if you are running
-Terraform in automation. Instead,
+OpenTofu in automation. Instead,
 [select a different backend which supports remote state](/docs/language/settings/backends/configuration) and configure it
 within your root module, which ensures that everyone working on your
 configuration will automatically retrieve and store state in the correct shared