Skip to main content
This is the workflow we recommend for keeping Authsignal configuration consistent across dev, QA, and production with the Authsignal Terraform provider. You can set up a new environment from the same code.

​
Overview

Each environment has its own Authsignal tenant. You build and test configuration in the dev tenant using the portal. You then capture the changes as code in a shared module and apply that module to QA and then production.
The dev tenant is edited by hand in the portal. Changes are captured as code in the shared module and reviewed in a pull request, then applied in order to QA and production.

Changes start in dev and are applied to QA, then production

Once it’s set up, a plan against any tenant shows whether it matches the module. No changes means it does.

​
What’s covered

The module holds whichever parts of the Authsignal configuration you choose to manage, such as authenticators, flows, rules, and branding. You can bring in new resources at any time. The resources the provider supports are listed on the Terraform Registry. A few values usually have to differ per tenant, such as web addresses and the tenant name shown to users. These are variables, which you set in each environment’s tfvars. Everything else is identical everywhere. Resources that should only exist in some environments, such as a list of test account emails used in dev and QA, sit behind a variable that you switch on per environment.

​
Repository layout

One shared module holds the Authsignal configuration. Each environment has a small folder that applies the module to one tenant, with its own state file and tfvars.

​
Setup

  1. Configure the dev tenant in the portal.
  2. Capture the dev configuration as code in the shared module. Terraform can generate a starting point from dev, or you can write the code by hand.
  3. Import dev into Terraform state. The plan should show no changes to the tenant.
  4. Add QA and production one at a time. Terraform creates the configuration in each new tenant, importing anything the tenant already has.

​
Day to day

You still make changes to the dev tenant in the portal. You then update the module until dev’s plan is clean and open a pull request. Once it’s approved, you apply the change to QA and then production. If you change an existing resource in the QA or production tenant, Terraform reverts it the next time it’s applied there. Anything new you add in those tenants isn’t managed by Terraform, so it’s left alone. Dev should be the only tenant anyone edits by hand.