Support Forums

Infrastructure as code options?

We are trying to manage all of our servers/services via an infrastructure as code model, where we have a separate code repo (in terraform/terragrunt) that specifies what versions of other repos should be deployed/live for different environments.

I’m struggling to find a way to work with Netlify in this manner. There are terraform providers for setting up a site or creating new build hooks, but what we’re trying to do is along the lines of updating a SHA that’s checked in to the terraform repo and having that trigger a deploy to Netlify (typically, a terraform module would check to see what’s CURRENTLY deployed and whether it’s up to date and then if not, use the new value to trigger the deployment).

One idea I had was to stop auto-publishing and use terraform to change the git tag or SHA that is deployed on Netlify, but as far as I can tell, Netlify ONLY allows you to configure a branch and always sets the HEAD of the branch. I do understand that we can control builds and deploys without using Netlify’s build but I see no way to control this in a configuration-based manner.

I’m wondering if anyone out there is using Netlify with terraform or other methodology for this kind of workflow? (Please don’t just forward URLs to terraform providers without explaining something about them, I’ve been combing through docs and don’t see a straightforward path)!

Thanks for any ideas/help…

Hi @uooq,

You’re right about this:

Netlify will always build for the latest commit on a branch - even if you try to retry a specific deploy, it’s always the HEAD that’s fetched and re-built.

We currently don’t have a way to specify which commit to build for, so chances are you would not be able to make use of Netlify’s build system.

The only way that might make this remotely possible is that you can use [skip ci] or [skip netlify] anywhere in the commit message which could prevent any builds for that commit. Then, you can perform any kind of checks that you need and trigger a build by sending in another commit without those flags in the commit message and sending the content of that particular commit as the head.

So, the workflow could be something like:

Push to your repo with one of the flags in the commit message → do your stuff → using Netlify API, change the published branch of your website to a new branch name → push the required commit’s content to that new branch → Netlify will build for that commit → Delete the branch.

Not a perfect workflow, but might work.

1 Like

To add to Hrishikesh’s comments, @uooq - yup, there is no maintained terraform provider for Netlify for you to use. The archived one: https://github.com/hashicorp/terraform-provider-netlify worked well in the past but Hashicorp was not interested in maintaining it and offered to transfer it to us, but never did, instead archiving it. You could definitely fork and extend for your use if you insist on managing things using exactly that software. I don’t think that has been maintained for some time so may need some updates to get working, and you’ll see how to figure those out below.

My advice for finding a solution is to take a step back to get more clarity about what you are trying to accomplish. What you have asked for is help with a solution which you are proposing - we do better when you bring us a problem: “I want to manage my netlify config in an automated fashion” - great, we have a REST API (https://open-api.netlify.com/) and a JS library (https://github.com/netlify/js-client) to do so! Want to use terraform? OK, there is a starting place in the repo I linked + the API docs I also linked.

Hope something in there can help you accomplish your goals!

1 Like

Thanks for the thoughtful reply-- I will gladly take you up on your suggestion to describe the end result we want!


  • We already use terraform to manage our non-Netlify backend deployments-- servers, databases, dns configurations, etc. Terraform gives us two things that we really like/want to keep & extend
  • Benefit 1: For each tier of our environment (e.g. dev, staging, pre-production, production) we know exactly what is deployed where because that configuration is checked in (i.e. the terraform repo is a documentation of our whole system).
  • Benefit 2: Terraform itself keeps track of what needs to change if we edit that repo. So, if I change the SHA of the API server for the staging environment, terraform looks at our current staging environment and knows that it needs to be updated to that SHA but recognizes that our job server is current/does not need to be refreshed.

So-- what we’re looking for is SOME way to extend this type of system to our static webapp-- a complex but purely browser-based application that is frequently updated and has close connections to our api server.

We’d like not just a means of triggering new deployments via api calls or by pushing to a specific branch, but a terraform module that is smart enough to know when the current deployment is current or needs something new to happen. That smarts of detecting the difference between the code description of what’s deployed and the actual version of what’s deployed is fundamental to our workflow and our infrastructure as code goals.

Now, I’m 100% sure that given a little time and practice, we could ourselves write a new terraform module that would wrap the full-featured Netlify apis to do just this for us! That being said, we’re not a devops shop and we’ve got a long laundry list of “to dos” for our own application that mean that we’re not going to tackle this kind of project in the foreseeable future.

if we can’t find something out there that fits into our workflow, we’ll do one of two things: create some CI automation to do netlify deployments or start using some designated branches (e.g. having a branch for “pre-production” and one for “staging” etc) and just leave our front-end out of our terraform/infrastructure as code system altogether. But in either case, we’ll be losing some aspects of the workflow and inherent documentation we get by having a full-featured terraform provider that doesn’t just provision sites, but can also manage which version of our code is on the site.

I know I’ve been a little specific about HOW we use terraform here, and we’re more than willing to use another system— the key parts are that we have a way to record in code (separate from the code being deployed) what version of our apps should be currently running in each environment and that we can manage changes to that versioning via pull requests and merges to the infrastructure codebase.


Hi, would still love to hear your thoughts-- I think I did what you asked and explained the scenario rather than the proposed solution.