Terraform Provider

The Featureflip Terraform provider manages your flag configuration as code through the Management API: projects, environments, feature flags (including variations and per-environment targeting), user segments, and SDK keys.

It is published on the Terraform Registry as canopy-labs/featureflip, and developed in the open at canopy-labs/terraform-provider-featureflip.

Installation

terraform {
  required_providers {
    featureflip = {
      source  = "canopy-labs/featureflip"
      version = "~> 0.1"
    }
  }
}

provider "featureflip" {
  organization = "acme-corp"
  # token via FEATUREFLIP_TOKEN environment variable (recommended),
  # or: token = var.featureflip_token
}

Authentication

Create an API token in the Featureflip dashboard — tokens cannot be created through the public API:

• Service token (ffs_…) — recommended. Organization Settings → Service Tokens. Scoped to one organization with a role and an optional project allowlist. Use Member or Admin; Viewer tokens cannot write.
• Personal access token (ffp_…). Acts as your user across your organizations.

Prefer the FEATUREFLIP_TOKEN environment variable over putting the token in configuration. organization and base_url can likewise be set via FEATUREFLIP_ORGANIZATION and FEATUREFLIP_BASE_URL.

Quickstart

resource "featureflip_project" "web" {
  key         = "web"
  name        = "Web App"
  description = "Customer-facing web application"
}

# Boolean flags get true/false variations automatically.
resource "featureflip_feature_flag" "new_checkout" {
  project = featureflip_project.web.key
  key     = "new-checkout"
  name    = "New Checkout Flow"
  type    = "Boolean"
  tags    = ["checkout"]
}

# Non-Boolean flags declare their variations inline.
resource "featureflip_feature_flag" "banner_text" {
  project = featureflip_project.web.key
  key     = "banner-text"
  name    = "Banner Text"
  type    = "String"

  variations = [
    { key = "control", name = "Control", value = "Welcome!" },
    { key = "variant", name = "Variant", value = "Hi there!" },
  ]
}

Targeting rules

featureflip_flag_environment manages a flag’s state and targeting in a single environment. List position is rule priority:

resource "featureflip_flag_environment" "new_checkout_prod" {
  project           = featureflip_project.web.key
  flag              = featureflip_feature_flag.new_checkout.key
  environment       = "production"
  enabled           = true
  default_variation = "false"

  rules = [
    {
      description = "Beta users always get the new checkout"
      variation   = "true"
      segment     = featureflip_segment.beta_users.key
    },
    {
      description        = "50% rollout in Germany"
      variation          = "true"
      rollout_percentage = 50
      condition_groups = [
        {
          operator = "And"
          conditions = [
            { attribute = "country", operator = "Equals", values = ["DE"] },
          ]
        },
      ]
    },
  ]
}

Resources and data sources

Resource	Manages
featureflip_project	A project
featureflip_environment	An environment within a project
featureflip_feature_flag	A flag and its variations
featureflip_flag_environment	A flag’s per-environment state and targeting rules
featureflip_segment	A reusable user segment
featureflip_sdk_key	An SDK key (destroying it revokes the key)

Data sources exist for reading an existing featureflip_organization, featureflip_project, featureflip_environment, featureflip_feature_flag, and featureflip_segment.

Every resource supports terraform import, so you can adopt flags that already exist:

terraform import featureflip_feature_flag.new_checkout web/new-checkout

Things to know before you apply

It manages flag configuration, not flag state. The provider owns which flags exist, their variations, and their targeting rules. It is not built for flipping a flag on and off during an incident: that is a dashboard or API action, and a Terraform apply is a slower path to it. A common pattern is to manage projects, environments, flags, and segments in Terraform while leaving day-to-day toggling to the dashboard.

rules is authoritative. Once you set rules on a featureflip_flag_environment, Terraform owns every rule in that flag-environment, and rules added in the dashboard are removed on the next apply. Destroying the resource deletes the managed rules and disables the flag in that environment, leaving the fallthrough configuration in place.

SDK keys are sensitive, and destroying one revokes it. The plaintext value of a featureflip_sdk_key is only available at creation and is stored in Terraform state, so protect your state. Destroying the resource revokes the key, which cannot be undone. Imported keys cannot recover their plaintext.

Reference

Full resource and data-source documentation, including every argument and attribute, is published on the Terraform Registry.

For a worked walkthrough covering install, a first project and flag, importing flags you already have, and where to stop putting flag config in code, see Feature Flags as Code: Managing Featureflip with Terraform.