I know terraform a bit, but in the past I worked just with one terraform repository serving all infrastructure (with modules per provider/function).

   |- modules
   |   |- gcp
   |       |- main.tf
   |       |- variables.tf
   |   |- vsphere
   |       |- main.tf
   |       |- variables.tf

Now I have following situation:

  • one Azure subscription
  • Need for multiple separated infrastructure "buckets" - per 2 different projects, and I would like to separate test/dev (which should be more ephemeral) from production servers (long life).
  • Need to hand over the infra per project in the future

Is it convenient and feasible to have:

  • a bit of terraform code in each project repository, to keep it together
  • many tfstates on same Azure subscription (one state per each infra bucket) that are isolated on Azure side by (resource groups?)

Any advice Guys?

1 Answer 1


You may want to use Terraform Cloud this will allow you to publish your modules from the project repos to a registry and you can then consume these modules from another repo containing the terraform that you use for the IaC deployments you then need to work out what the pipeline triggers for this repo will be.

Terraform cloud will also give you remote storage of the tfstate files and you will need a state per environment that you deploy. Azure DevOps and GitHub (and probably all other CI/CD providers) let you define environments and associate variables with them so you can use these to define which state file and resource group to target along with any other environment specific values you may need to use.

  • I am afraid of having conflicts between diffrent "infra buckets" if they ran on same Azure subscription. How Terraform cloud solves that?
    – Wojtas.Zet
    Nov 12, 2021 at 13:48
  • To avoid conflicts you ensure that the pipeline uses the correct state file and resource groups for the "infra bucket". For example, if you have multiple stages for dev, test, prod infra then use a pipeline environment to group the variables for state and resource groups. TF Cloud is more for the module registry (so you can keep the module definitions in the project repo) and remote state storage which makes them easy to consume but you could achieve the same for example by using a blob storage for the state and publish the modules to Azure DevOps Artifacts. Nov 12, 2021 at 15:35
  • I'm already dealing with this but in AWS, I had a discussion about this here. And you are completely correct you do not need TF Cloud, you can achieve this by yourself with S3 or SA. Dec 16, 2021 at 12:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.