terraform console Command: Usage and Examples

Sometimes you need to check how individual parts of your Terraform configuration work. With the terraform console command, you can test expressions and functions directly in the terminal without changing your configuration files or infrastructure.

Learn how to use the terraform console command and where it fits into your Terraform workflow.

Learning how to use the terraform console command.

What Is the terraform console Command?

The terraform console command opens an interactive prompt in your terminal.

When you see the > prompt, you can type an expression and press Enter to see the result. Terraform expressions are pieces of code that calculate or retrieve values.

Developers use them to check variable values, try out Terraform's built-in functions, and look up information about specific resources. For example, you can test how Terraform generates a server hostname, calculate a subnet, or read an IP address from the state file.

Try entering this expression with one of Terraform's built-in functions:

> upper("my first console expression")

The upper function converts the text to uppercase, and the console returns the result.

The console uses a Read-Eval-Print Loop (REPL). This means it reads an expression, evaluates it, displays the result, and waits for you to enter another expression.

You can continue trying out different expressions for as long as you need. The expressions you enter in the console do not change your configuration or any resources you already deployed.

\When you are ready to close the console, type:

exit

You can also press Ctrl+C or Ctrl+D to exit.

How Does terraform console Work?

The console has access to your project's configuration files, providers, modules, and backend. This means that when you write expressions, you can use values from your project, including:

Values set in variable and locals blocks.
Input values loaded from .tfvars files.
Information about managed resources, like the server's hostname, IP, or location.
Data from external platforms, like AWS or phoenixNAP BMC, through Terraform data sources.
Values exposed by child modules.
The name of the current Terraform workspace.

Note: Some values, such as the server's IP address or ID, are usually not available until after you deploy the infrastructure using terraform apply.

Besides checking values, you can also use the console to test Terraform functions, especially when working with text, lists, maps, and other Terraform data types. For example, you can use cidrsubnet to calculate smaller subnets from a network range, length to count items in a list, or replace to modify part of a string.

Terraform has a lot of built-in functions. You can test them in the console to see what they return before adding them to your configuration.

For example, if you use a Terraform expression to generate BMC server names, you can try it in the console first to see if it returns the names you expect. Once you are happy with the result, you can use the expression in your configuration and continue with terraform plan.

terraform console Syntax and Options

Like with other Terraform commands, the syntax for opening the console is very simple:

terraform consloe [options]

If you run the command without options, Terraform opens the console right away and waits for your input.

The terraform console options give you more control over how the console works and evaluates expressions. The table below lists some of the most commonly used options:

Option	Description
`-plan`	This option creates a plan before opening the console and lets you evaluate expressions based on the planned state instead of the current state.
`-var='[name]=[value]'`	You can use this option to provide an input variable value directly from the command line when opening the console.
`-var-file=[filename]`	Use this option to load input variable values from a .tfvars file instead of entering them manually through the command line.
`-scope=[module_address]`	By default, the console evaluates expressions in the root module. This option lets you work with values from a specific child module instead.
`-input=false`	This option turns off prompts to enter missing input values. It's mainly used in automated setups, like scripts and CI/CD pipelines.

Note: Checking your configuration with terraform console is very useful in Infrastructure as Code workflows, especially when managing complex deployments.

terraform console Examples

The following examples use a Terraform configuration for phoenixNAP Bare Metal Cloud (BMC). However, the terraform console command works the same way with other Terraform providers.

To try the examples locally, create a new directory for your Terraform test project and copy the following configuration into your main.tf file:

terraform {
  required_providers {
    pnap = {
      source = "phoenixnap/pnap"
      version = "~> 0.33.0"
    }
  }
}

provider "pnap" {}
variable "environment" {
  type = string
  default = "test"
}

variable "network_cidr" {
  type = string
  default = "10.20.0.0/16"
}

locals {
  server_name = "bmc-${var.environment}-email"

  server_types = {
    test = "s1.c1.small"
    prod = "s1.c2.large"
  }
}

resource "pnap_server" "email_server" {
  hostname = local.server_name
  os = "ubuntu/jammy"
  type = local.server_types[var.environment]
  location = "ASH"
  install_default_ssh_keys = true
}

Save and close the file.

Before opening the console, you need to initialize the working directory so Terraform can access the providers and modules required by the configuration. Enter the following command:

terraform init

The terraform init command prepares the directory so the console can access all the necessary components. Use the following command to open the console:

terraform console

You can now test functions, variables, and local values. However, you will not be able to check values that are assigned during deployment, such as the server's IP, until you provision the infrastructure.

Testing Built-In Functions

In the example BMC configuration, a map assigns different server types to the test and prod environments. You can use the lookup function to find out which server type is assigned to the current environment.

Enter the following expression:

> lookup(local.server_types, var.environment, "not configured")

The lookup function checks the server_types map for the current environment, which is test, and returns its assigned server type, s1.c1.small. If there is no matching entry, it returns a not configured message.

The Terraform lookup function in the console.

You can use the replace function to see what a hostname would look like in a different environment:

> replace(local.server_name, "test", "prod")

The function takes the current bmc-test-email hostname and swaps test for prod. The console shows only the new value. It does not update the hostname in your configuration or any deployed infrastructure.

The Terraform replace function in the console.

startswith is another useful function. It checks if a string begins with specific text. For example, to see if the hostname follows your naming convention, enter:

> startswith(local.server_name, "bmc-")

The Terraform startswith function in the console.

Terraform returns true because the hostname starts with bmc-.

Using String Interpolations

String interpolation lets you insert variables and other Terraform values into text. For example, the BMC configuration uses the environment variable to create a unique hostname:

> "bmc-${var.environment}-email"

Right now, var.environment is set to test, so Terraform adds it to the hostname.

String interpolations in terraform console.

You can use this method to combine several values in the same expression:

> "Server ${local.server_name} uses ${local.server_types[var.environment]}"

Terraform reads the server_name and looks up the server_type assigned to the test environment.

Combining values in strings in terraform console.

The resulting message shows that the bmc-test-email server uses a s1.c1.small server type.

Testing Network and Subnet Calculations with Built-In CIDR Functions

Terraform has several CIDR functions for working with IP addresses and network ranges. You can use these functions to calculate subnets, host addresses, and network masks before updating your network configuration.

The following network range is defined in main.tf:

variable "network_cidr" {
  type = string
  default = "10.20.0.0/16"
}

You can divide this network into smaller /24 subnets. To do this, open the console and enter:

> cidrsubnet(var.network_cidr, 8, 3)

The cidrsubnet function uses three arguments:

var.network_cidr. This is the starting network range.
8. The number of extra bits used to make the subnet smaller.
3. The subnet number to calculate, starting from zero.

In this example, Terraform calculates the fourth /24 subnet inside the original /16 network.

The cidrsubnet function in terraform console.

You can also calculate a specific host IP address within that subnet:

> cidrhost("10.20.3.0/24", 10)

The cidrhost function gives you the IP address at host number 10 in the network.

The cidrhost function in Terraform console.

To see the subnet mask, use the cidrnetmask function:

> cidrnetmask("10.20.3.0/24")

Terraform converts the /24 network prefix into the matching subnet mask.

The cidrmask function in terraform console.

Note: These functions only calculate IP addresses and ranges. They do not check if the addresses are already in use or if the BMC platform will accept the network configuration.

Working with Lists, Maps, and for Expressions

In Terraform, lists and maps are used to store groups of related values. You can use the console to view these values and test them in expressions.

For example, the BMC configuration includes a local map that lists different server types:

locals {
  server_types = {
    test = "s1.c1.small"
    prod = "s1.c2.large"
  }
}

To check which server type is assigned to the test environment, enter:

> local.server_types["test"]

The console returns the s1.c1.small server type. To check the value for the production environment, use:

> local.server_types["prod"]

This time the server type is s1.c2.large.

You can also use a for expression to handle several values at the same time:

> [for env in keys (local.server_types) : "bmc-${env}-email"]

The keys function retrieves the environment names from the server_types map. The for expression then goes through each name and uses it to build a server hostname. Terraform returns the results as a list:

Using the for expression in terraform console.

You can also use a for expression to filter a map. For example, to return only the production server type, enter:

> { for env, size in local.server_types : env => size if env == "prod" }

The expression checks each environment in the map and returns only the one named prod.

Piping Input Expressions for Automated CI/CD Scripting

The terraform console command is usually used interactively, but you can also pass expressions to it from scripts.

Instead of opening the console and typing each expression, you can use a pipe (|) to send the expression straight to Terraform. For example, enter the following command in your Linux terminal:

echo 'local.server_name' | terraform console

The echo command sends the expression to the console, and the pipe passes it as input. The console then evaluates the expression, shows the result, and exits automatically.

Using the echo command to pipe expressions to the Terraform console.

You can also use this method to test network calculations in a CI/CD pipeline. For example, to check if the subnet calculated from your configuration matches the expected range, enter:

echo 'cidrsubnet(var.network_cidr, 8, 3) == "10.20.3.0/24"' | terraform console

This expression compares the calculated subnet with 10.20.3.0/24. If they are the same, Terraform returns true.

A CI/CD expression in the terraform console.

You can use this result in a script to check network values before moving on to deployments. The script needs to check the returned value and decide whether to continue.

Querying Existing BMC Resource Attributes and State Data

If you have a BMC account and have already deployed a server with Terraform, you can use the terraform console command to check the attributes in the state file.

To check the hostname of the BMC server from our earlier configuration, open the console and enter:

> pnap_server.email_server.hostname

Terraform shows the hostname stored for that resource.

"bmc-test-email"

To find out where the server was deployed, enter:

> pnap_server.email_server.location

In this example, the server was deployed in Ashburn:

"ASH"

The console can also show details that the BMC platform assigns during deployment. For example:

> pnap_server.email_server.public_ip_addresses

Terraform returns the public IP addresses assigned to the server.

"203.0.113.10"

If you want to look at more than one attribute, you can enter the resource address without naming a specific attribute:

> pnap_server.email_server

Terraform will show an object with all the available attributes and their values. This is useful if you want to check a resource without opening the state file directly.

terraform console Limitations and Common Troubleshooting

The following sections explain common Terraform problems and how to resolve them.

Resolving State Lock Failures and Concurrent Execution Errors

Terraform uses state locking to prevent several operations from changing the same state at the same time. In some Terraform versions, opening the console locks the state. This means other commands cannot access the same state until you exit the console.

If you get an error saying Terraform cannot acquire the state lock, go back to the terminal where the console is running and type:

exit

Terraform will close the console and release the lock. After that, you can try the command again.

The opposite can also happen. The console might not open if another operation is already holding the lock. If this happens, wait for the other operation to finish, then try again.

A process can stop suddenly and leave a stale lock. If you are using a remote backend, you may need to release the lock yourself with the following command:

terraform force-unlock [lock_id]

You can find the lock ID in the error message. Use this command only if you are sure the lock is stale.

Managing Uncomputed Values and Unknown Attributes Before Apply

Some resource attributes are only assigned when Terraform creates the actual infrastructure. For example, if you have not deployed the BMC server yet, Terraform does not know what server ID the platform will assign.

If you check this value in the console, Terraform returns the known after apply message instead of the actual value.

known after apply error message in terraform console.

This is normal. The value is not available because the BMC server has not been created. You can use the -plan option to check expressions with values from a planned deployment.

If you are already in the console, exit your current session and start a new one using the following command:

terraform console -plan

Terraform generates a plan before opening the console. It can now calculate the missing attributes from the planned configuration.

Certain values, like those assigned by the BMC platform (e.g., server ID), may still be unknown. To get these values, you need to deploy the resources first and then check them in the console.

Addressing Missing Initialization and Unresolved Provider References

terraform console will work in a new project directory even if you have not initialized it yet. However, Terraform will not be able to access the providers or modules in the configuration.

For example, in our BMC setup, the pnap_server resource needs the pnap provider to work. If Terraform cannot find this provider, it will show an error saying the required plugin is missing.

To fix this, you need to initialize the working directory before opening the console:

terraform init

Terraform will read your configuration, download the provider plugins and modules, and set up the directory. After the initialization is done, try opening the console again.

If Terraform still cannot find the resource from your expression, make sure the resource name matches what you have in your configuration.

For example, in the main.tf file, the server is defined as:

resource "pnap_server" "email_server" {
  hostname = local.server_name
  os = "ubuntu/jammy"
  type = local.server_types[var.environment]
  location = "ASH"
  install_default_ssh_keys = true
}

To reference this resource in the console, you need to enter the following expression:

> pnap_server.email_server.hostname

If you use a different resource name, like pnap_server.web_server, you will get a Reference to undeclared resource error.

Fixing Syntax Errors in Multi-Line Expressions

Terraform expressions are sometimes longer than one line, especially when you work with for expressions. The console is interactive, and you can enter long expressions over several lines. Each new line starts with a colon (:) prompt.

For example, this for expression creates server hostnames for the test and prod environments:

> [for env in keys (local.server_types) :
:    "bmc-${env}-email"
: ]

If you press Enter after the first line, Terraform automatically displays the : prompt instead of evaluating the expression. This means your expression is incomplete, and Terraform is waiting for more input.

When you add the closing bracket and press Enter, Terraform shows the hostnames:

[
  "bmc-prod-email",
  "bmc-test-email",
]

However, the console can also keep waiting for input when you make a syntax mistake. For example, if you forget the closing bracket ], Terraform keeps displaying the : prompt because it thinks the expression is still not complete.

If the console stays in multiline input mode, press Enter on an empty line to make Terraform evaluate what you have typed so far. This can show a syntax error that helps you find the problem.

You can also press Ctrl+C to cancel the unfinished expression and go back to the regular console prompt.

terraform console Best Practices

Follow these best practices when using terraform console:

Test as many expressions as you need to ensure your functions and calculations return the results you expect before adding them to your configuration. The console has no limits on the number of evaluations, so feel free to experiment.
If your expressions get too long, it might be easier to write them in a locals block in your Terraform configuration. You can then use the console to check the value of that local.
Initialize the working directory before opening the console, so that Terraform can find the providers and modules your configuration uses.
Use the -plan option when you need to test values and configuration changes that have not been applied yet.
Do not use the console as a replacement for terraform validate or terraform plan. Even if an expression works in the console, other parts of your configuration might still have errors or deployment problems.
Be careful about what resource attributes you display in the terminal. The console can show values stored in state, including sensitive information.
If you are working with automation scripts, use the terraform output command with the -raw or -json options. This is better than retrieving these values through terraform console.
Close the console when you are done with evaluating expressions. If you leave it open, it can lock the state and block other operations.

Conclusion

You can now use the terraform console command to test expressions and check resource values before making changes to your infrastructure.

Another great way to inspect the current Terraform state or review a saved deployment plan is the terraform show command.

Was this article helpful?

YesNo