Terraspace Concepts

Up and Down

The terraspace up and terraspace down commands are how you create infrastructure with Terraspace. The terraspace up ultimately calls terraform apply and terraspace down calls terraform destroy. Before calling the terraform commands, terraspace does additional processing. For example, terraspace will build common source code files from config/terraform along with the deployed module.

Modules vs Stacks

Both modules and stacks are terraform modules. The difference is organizational and how they are can be used.

For example, the app1 stack could be designed to use an instance module. Another, app2 stack could use an instance and rds modules.

There are no hard rules. Stacks can be reusable and you provide the tfvars config. It’s up to you. Here are some more Tfvars Location Thoughts.

Conventions Over Configuration

Terraspace uses Conventions Over Configuration to remove boilerplate setup and mental overhead. The app/modules, app/stacks, and config/terraform are where you organized your code by convention and it should just work. You also put Tfvars files in conventional folders and Terraspace will automatically use them. The “batteries are included but replaceable” You can override things as necessary.

Tfvars Layering

Terraspace introduces Tfvars Layering. You can use the same infrastructure code with different tfvar files to create multiple environments like dev, prod, uat, stage, etc. Layering DRYs up the usage of multiple tfvar files. Additionally, Layering allows you to use same infrastructure code to deploy to multiple regions and or accounts.


Terraspace ships with a testing framework. It allows you to test with real resources. The testing works by creating a “test harness”, which is a generated terraspace project. Then terraspace up is ran. It’s what you would normally do manually, but automated.

More tools: