Note: Premium video content requires a subscription.

Best of Both Worlds

The Terrafile approach simplifies managing modules. The advantage of using a Terrafile is centralization. You can centrally define, manage, and update modules. To define modules, add them to Terrafile:


org "boltops-tools" # set default org
mod "s3", source: "git@github.com:boltops-tools/terraform-aws-s3"
mod "sg", source: "terraform-aws-modules/security-group/aws", version: "3.10.0"

To install the modules, run:

terraspace bundle

Modules are downloaded to your vendor/modules folder. You can easily look at the module source code when you need to debug.


Here’s a demo stack that uses the downloaded vendor/modules/s3 module.


resource "random_pet" "this" {
  length = 2

module "bucket" {
  source     = "../../modules/s3" # looks up either app/modules/s3 or vendor/modules/s3
  bucket     = "bucket-${random_pet.this.id}"
  acl        = var.acl

A module downloaded to vendor/modules/s3 is sourced same way as if they were defined in app/modules/s3. This is because Terraspace considers multiple lookup paths. Docs: Lookup Paths

Here’s an example repo based on these docs: boltops-tools/terraspace-demo-terrafile


A Terrafile.lock file is also generated. This file can be committed to version control to ensure that everyone on the team uses the exact same version.

Pure Terraform Approach

Of course, you can still use the typical approach of declaring the source directly in the module source code. Here are some examples from the docs:

module "consul" {
  source = "hashicorp/consul/aws"
  version = "0.1.0"

module "example" {
  source = "github.com/hashicorp/example"

Terraspace provides flexibility. You can use either or both approaches. You get the best of both worlds.

More tools: