> ## Documentation Index
> Fetch the complete documentation index at: https://docs.authsignal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Import the dev tenant into Terraform

> Hand the dev tenant's existing configuration over to Terraform. Nothing in the tenant changes.

Terraform starts managing the resources already set up in dev, exactly as they are. Nothing in the tenant changes.

## Prerequisites

* The finished module from [Build the module from the generated code](/knowledge-base/terraform/build-module).
* The [environment variables](/knowledge-base/terraform/repository-setup#connecting-to-a-tenant) set for the dev tenant.

## 1. Add the imports

Create `envs/dev/imports.tf` with the same five imports as the scratch folder. Resources inside a module have addresses that start with `module.` and the module's name from `main.tf`, so the addresses now start with `module.authsignal.`.

```hcl theme={null}
# envs/dev/imports.tf
import {
  to = module.authsignal.authsignal_email_otp_authenticator_configuration.email_otp
  id = "email-otp"
}

import {
  to = module.authsignal.authsignal_passkey_authenticator_configuration.passkey
  id = "passkey"
}

import {
  to = module.authsignal.authsignal_flow.sign_in
  id = "sign-in"
}

import {
  to = module.authsignal.authsignal_theme.theme
  id = "theme"
}

import {
  to = module.authsignal.authsignal_message_overrides.messages
  id = "messages"
}
```

## 2. Plan

```bash theme={null}
cd envs/dev   # from the repository root
terraform init
terraform plan -out=tfplan
```

The plan should end with:

```text theme={null}
Plan: 5 to import, 0 to add, 0 to change, 0 to destroy.
```

If the module has a secret value, expect `1 to change` on the Email OTP configuration. Applying it sends the key.

If it shows any other changes, the module doesn't match the tenant yet. Update the module, not the tenant, and plan again. If an attribute comes from a variable, update its value in `envs/dev/terraform.tfvars` instead. [Reading a plan](/knowledge-base/terraform/repository-setup#reading-a-plan) explains how to read the differences.

## 3. Apply

```bash theme={null}
terraform apply tfplan
rm imports.tf tfplan
```

The import blocks have done their job once applied. Deleting them keeps them from being copied into the next environment.

The import is written to state on apply. A plan on its own doesn't write anything. Applying the saved plan means Terraform does exactly what you reviewed, even if someone changed the tenant in between.

Don't commit `tfplan`. It contains the full state of every resource in the plan.

## Verify

```bash theme={null}
terraform plan
```

It should report `No changes`. Commit the module and the `envs/dev` files. Dev is now managed by Terraform.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.