2020-10-27 02:15:36 +01:00
---
2021-12-15 03:41:17 +01:00
page_title: Modules Overview - Configuration Language
description: >-
Modules are containers for multiple resources that are used together in a
configuration. Find resources for using, developing, and publishing modules.
2020-10-27 02:15:36 +01:00
---
# Modules
> **Hands-on:** Try the [Reuse Configuration with Modules](https://learn.hashicorp.com/collections/terraform/modules?utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) collection on HashiCorp Learn.
_Modules_ are containers for multiple resources that are used together. A module
consists of a collection of `.tf` and/or `.tf.json` files kept together in a
directory.
Modules are the main way to package and reuse resource configurations with
Terraform.
## The Root Module
Every Terraform configuration has at least one module, known as its
_root module_, which consists of the resources defined in the `.tf` files in
the main working directory.
## Child Modules
A Terraform module (usually the root module of a configuration) can _call_ other
modules to include their resources into the configuration. A module that has
been called by another module is often referred to as a _child module._
Child modules can be called multiple times within the same configuration, and
multiple configurations can use the same child module.
## Published Modules
In addition to modules from the local filesystem, Terraform can load modules
from a public or private registry. This makes it possible to publish modules for
others to use, and to use modules that others have published.
The [Terraform Registry](https://registry.terraform.io/browse/modules) hosts a
broad collection of publicly available Terraform modules for configuring many
kinds of common infrastructure. These modules are free to use, and Terraform can
download them automatically if you specify the appropriate source and version in
a module call block.
Also, members of your organization might produce modules specifically crafted
2021-12-15 03:41:17 +01:00
for your own infrastructure needs. [Terraform Cloud](/cloud) and
[Terraform Enterprise](/enterprise) both include a private
2020-10-27 02:15:36 +01:00
module registry for sharing modules internally within your organization.
## Using Modules
2021-12-15 03:41:17 +01:00
- [Module Blocks](/language/modules/syntax) documents the syntax for
2020-10-27 02:15:36 +01:00
calling a child module from a parent module, including meta-arguments like
`for_each`.
website: Break up main Modules and Module Development pages
This one is a lot like the previous two commits, but slightly more complex:
- Only adding one new meta-argument page, for `providers`; otherwise, it just
re-uses the dual-purpose pages I made in the resources commit.
- About that `providers` argument: The stuff that was relevant to consumers of a
module went in that meta-argument page, but there was also a huge deep dive on
how the _author_ of a re-usable module should handle provider configurations
in cases where inheriting the default providers isn't sufficient. THAT, I
moved into a new page in the module development section. (For the consumer of
a module, this should all be an implementation detail; the module README
should tell you which aliased providers you need to configure and pass, and
then you just do it, without worrying about proxy configuration blocks etc.)
- The "standard module structure" recommendations in the main module development
page gets a page of its own, to make it more prominent and discoverable.
- Same deal with using the old URL as a landing page, at least for the main
module calls page. It didn't seem necessary for the module development page.
2020-11-13 03:21:35 +01:00
2021-12-15 03:41:17 +01:00
- [Module Sources](/language/modules/sources) documents what kinds of paths,
2020-10-27 02:15:36 +01:00
addresses, and URIs can be used in the `source` argument of a module block.
website: Break up main Modules and Module Development pages
This one is a lot like the previous two commits, but slightly more complex:
- Only adding one new meta-argument page, for `providers`; otherwise, it just
re-uses the dual-purpose pages I made in the resources commit.
- About that `providers` argument: The stuff that was relevant to consumers of a
module went in that meta-argument page, but there was also a huge deep dive on
how the _author_ of a re-usable module should handle provider configurations
in cases where inheriting the default providers isn't sufficient. THAT, I
moved into a new page in the module development section. (For the consumer of
a module, this should all be an implementation detail; the module README
should tell you which aliased providers you need to configure and pass, and
then you just do it, without worrying about proxy configuration blocks etc.)
- The "standard module structure" recommendations in the main module development
page gets a page of its own, to make it more prominent and discoverable.
- Same deal with using the old URL as a landing page, at least for the main
module calls page. It didn't seem necessary for the module development page.
2020-11-13 03:21:35 +01:00
- The Meta-Arguments section documents special arguments that can be used with
every module, including
2021-12-15 03:41:17 +01:00
[`providers`](/language/meta-arguments/module-providers),
[`depends_on`](/language/meta-arguments/depends_on),
[`count`](/language/meta-arguments/count),
and [`for_each`](/language/meta-arguments/for_each).
website: Break up main Modules and Module Development pages
This one is a lot like the previous two commits, but slightly more complex:
- Only adding one new meta-argument page, for `providers`; otherwise, it just
re-uses the dual-purpose pages I made in the resources commit.
- About that `providers` argument: The stuff that was relevant to consumers of a
module went in that meta-argument page, but there was also a huge deep dive on
how the _author_ of a re-usable module should handle provider configurations
in cases where inheriting the default providers isn't sufficient. THAT, I
moved into a new page in the module development section. (For the consumer of
a module, this should all be an implementation detail; the module README
should tell you which aliased providers you need to configure and pass, and
then you just do it, without worrying about proxy configuration blocks etc.)
- The "standard module structure" recommendations in the main module development
page gets a page of its own, to make it more prominent and discoverable.
- Same deal with using the old URL as a landing page, at least for the main
module calls page. It didn't seem necessary for the module development page.
2020-11-13 03:21:35 +01:00
2020-10-27 02:15:36 +01:00
## Developing Modules
For information about developing reusable modules, see
2021-12-15 03:41:17 +01:00
[Module Development](/language/modules/develop).
