Terraform for Blockchain Infrastructure: Deploy Fabric and Besu Networks as Code

Most enterprise blockchain deployments still happen through shell scripts, manual CLI commands, and tribal knowledge locked in a senior engineer's head. When that engineer leaves, the network becomes a black box nobody dares to touch.

Infrastructure as Code solved this problem for cloud infrastructure years ago. But blockchain infrastructure has been stuck in the pre-IaC era — until now.

TL;DR: The ChainLaunch Terraform Provider gives you 62 resources and 20 data sources to manage Hyperledger Fabric and Besu networks declaratively. Organizations, nodes, channels, chaincode lifecycle, key management (Database, AWS KMS, HashiCorp Vault), automated backups, and monitoring — all from terraform apply. No more shell scripts. No more "works on my machine."

Why Does Blockchain Infrastructure Need IaC?

HashiCorp's 2024 State of Cloud Strategy Survey found that 49% of organizations use Terraform as their primary IaC tool (HashiCorp, 2024). Yet when those same organizations deploy blockchain networks, they typically fall back to manual processes. The consequences are measurable: Uptime Institute's 2024 Annual Outage Analysis found that 68% of outages are caused by configuration errors (Uptime Institute, 2024). In blockchain networks, where a misconfigured validator or expired TLS certificate can halt consensus, that risk is even higher.

Here's what a typical Fabric deployment looks like without IaC:

1. Generate crypto material with cryptogen or Fabric CA — 200+ lines of YAML config
2. Write channel configuration transaction files by hand
3. Create and join channels with multiple peer channel CLI calls
4. Package, install, approve, and commit chaincode across every org — 15+ sequential commands
5. Configure TLS certificates, anchor peers, and endorsement policies manually
6. Document everything in a wiki that's outdated by next week

A single multi-org Fabric network can require 50+ manual steps. Besu is simpler but still involves genesis file generation, validator key management, bootnode configuration, and consensus parameter tuning.

The result? Deployments that take days instead of minutes, environments that drift from each other, and zero reproducibility when something breaks at 2 AM.

{/* ============================================================ CHART 1: Manual vs IaC Deployment Steps (Horizontal Bar) ============================================================ */}

What Does the ChainLaunch Terraform Provider Cover?

The ChainLaunch Terraform Provider, published as kfsoftware/chainlaunch on the Terraform Registry, offers 62 resources and 20 data sources covering the full lifecycle of Hyperledger Fabric and Besu blockchain networks — from organization creation and node deployment through chaincode lifecycle, key management with AWS KMS and HashiCorp Vault, automated backups, and multi-instance collaboration. No other Terraform provider covers both Fabric and Besu with this level of depth. Most providers stop at node provisioning. This one handles everything from terraform init to a running network with deployed smart contracts.

Resource Coverage at a Glance

That's 62 resources and 20 data sources — enough to describe an entire blockchain infrastructure stack in HCL.

How Do You Deploy Your First Blockchain Network with Terraform?

Setting up the ChainLaunch Terraform provider takes less than a minute. You point it at your ChainLaunch instance, authenticate with either username/password or an API key, and you're ready to declare infrastructure. The provider handles all the complexity behind the scenes — generating crypto material, configuring TLS, setting up consensus parameters — so your Terraform files describe what you want, not how to build it. For CI/CD pipelines, use environment variables (CHAINLAUNCH_URL, CHAINLAUNCH_USERNAME, CHAINLAUNCH_PASSWORD) or API key auth (CHAINLAUNCH_API_KEY) to avoid hardcoded credentials.

Install the Provider

terraform {
  required_providers {
    chainlaunch = {
      source = "kfsoftware/chainlaunch"
    }
  }
}
 
provider "chainlaunch" {
  url      = "http://localhost:8100"
  username = "admin"
  password = "admin123"
}

Deploy a Fabric Network

A typical Hyperledger Fabric deployment involves creating organizations with MSP identities, launching peer and orderer nodes, forming a channel, joining nodes to that channel, configuring anchor peers for cross-org discovery, and deploying chaincode. Doing this manually requires dozens of CLI commands across multiple tools — cryptogen, configtxgen, peer channel, peer lifecycle chaincode — each with its own configuration format. The Terraform configuration below replaces all of that with a single declarative file. Every resource references the ones it depends on, and Terraform resolves the execution order automatically:

# Fetch the default key provider
data "chainlaunch_key_providers" "default" {}
 
# Create organizations
resource "chainlaunch_fabric_organization" "org1" {
  msp_id      = "Org1MSP"
  description = "Supply Chain Manufacturer"
  provider_id = data.chainlaunch_key_providers.default.default_provider_id
}
 
resource "chainlaunch_fabric_organization" "org2" {
  msp_id      = "Org2MSP"
  description = "Supply Chain Distributor"
  provider_id = data.chainlaunch_key_providers.default.default_provider_id
}
 
resource "chainlaunch_fabric_organization" "orderer_org" {
  msp_id      = "OrdererMSP"
  description = "Orderer Organization"
  provider_id = data.chainlaunch_key_providers.default.default_provider_id
}
 
# Deploy peer nodes
resource "chainlaunch_fabric_peer" "org1_peer0" {
  name            = "peer0.org1.example.com"
  organization_id = chainlaunch_fabric_organization.org1.id
  msp_id          = "Org1MSP"
  mode            = "docker"
  version         = "2.5.0"
 
  external_endpoint         = "peer0.org1.example.com:7051"
  listen_address            = "0.0.0.0:7051"
  chaincode_address         = "0.0.0.0:7052"
  events_address            = "0.0.0.0:7053"
  operations_listen_address = "0.0.0.0:9443"
 
  certificate_expiration = 365
  auto_renewal_enabled   = true
  auto_renewal_days      = 30
}
 
resource "chainlaunch_fabric_peer" "org2_peer0" {
  name            = "peer0.org2.example.com"
  organization_id = chainlaunch_fabric_organization.org2.id
  msp_id          = "Org2MSP"
  mode            = "docker"
  version         = "2.5.0"
 
  external_endpoint         = "peer0.org2.example.com:7051"
  listen_address            = "0.0.0.0:7051"
  chaincode_address         = "0.0.0.0:7052"
  events_address            = "0.0.0.0:7053"
  operations_listen_address = "0.0.0.0:9443"
 
  certificate_expiration = 365
  auto_renewal_enabled   = true
  auto_renewal_days      = 30
}
 
# Deploy orderer
resource "chainlaunch_fabric_orderer" "orderer0" {
  name            = "orderer0.example.com"
  organization_id = chainlaunch_fabric_organization.orderer_org.id
  msp_id          = "OrdererMSP"
  mode            = "docker"
  version         = "2.5.0"
 
  external_endpoint         = "orderer0.example.com:7050"
  listen_address            = "0.0.0.0:7050"
  admin_address             = "0.0.0.0:9443"
  operations_listen_address = "0.0.0.0:8443"
 
  certificate_expiration = 365
  auto_renewal_enabled   = true
  auto_renewal_days      = 30
}
 
# Create channel
resource "chainlaunch_fabric_network" "supply_chain" {
  name        = "supply-chain"
  description = "Supply chain tracking channel"
 
  peer_organizations = [
    {
      id       = chainlaunch_fabric_organization.org1.id
      node_ids = [chainlaunch_fabric_peer.org1_peer0.id]
    },
    {
      id       = chainlaunch_fabric_organization.org2.id
      node_ids = [chainlaunch_fabric_peer.org2_peer0.id]
    }
  ]
 
  orderer_organizations = [
    {
      id       = chainlaunch_fabric_organization.orderer_org.id
      node_ids = [chainlaunch_fabric_orderer.orderer0.id]
    }
  ]
 
  consensus_type = "etcdraft"
 
  etcdraft_options = {
    tick_interval       = "500ms"
    election_tick       = 10
    heartbeat_tick      = 1
    max_inflight_blocks = 5
  }
 
  channel_capabilities     = ["V2_0"]
  application_capabilities = ["V2_0"]
  orderer_capabilities     = ["V2_0"]
}
 
# Join peers to channel
resource "chainlaunch_fabric_join_node" "org1_join" {
  network_id = chainlaunch_fabric_network.supply_chain.id
  node_id    = chainlaunch_fabric_peer.org1_peer0.id
  role       = "peer"
}
 
resource "chainlaunch_fabric_join_node" "org2_join" {
  network_id = chainlaunch_fabric_network.supply_chain.id
  node_id    = chainlaunch_fabric_peer.org2_peer0.id
  role       = "peer"
}
 
# Set anchor peers
resource "chainlaunch_fabric_anchor_peers" "org1" {
  network_id      = chainlaunch_fabric_network.supply_chain.id
  organization_id = chainlaunch_fabric_organization.org1.id
  anchor_peer_ids = [chainlaunch_fabric_peer.org1_peer0.id]
  depends_on      = [chainlaunch_fabric_join_node.org1_join]
}
 
resource "chainlaunch_fabric_anchor_peers" "org2" {
  network_id      = chainlaunch_fabric_network.supply_chain.id
  organization_id = chainlaunch_fabric_organization.org2.id
  anchor_peer_ids = [chainlaunch_fabric_peer.org2_peer0.id]
  depends_on      = [chainlaunch_fabric_join_node.org2_join]
}

Run terraform apply and you have a production-grade Fabric network. Every resource is tracked in Terraform state, visible in terraform plan, and reproducible across environments.

Deploy a Besu QBFT Network

Besu networks follow the same declarative pattern but use Ethereum-compatible secp256k1 keys instead of Fabric's EC P-256 certificates. You create validator keys, define a network with QBFT consensus parameters (block period, epoch length, gas limit), and deploy nodes that automatically discover each other. The example below creates a 4-validator QBFT network with Prometheus metrics enabled on each node — the same setup that typically requires manual genesis file generation, static-nodes.json configuration, and per-node Docker Compose files:

data "chainlaunch_key_providers" "db" {}
 
# Create validator keys (secp256k1 — the Ethereum curve)
resource "chainlaunch_key" "validator" {
  count       = 4
  name        = "besu-validator-${count.index}"
  algorithm   = "EC"
  curve       = "secp256k1"
  provider_id = data.chainlaunch_key_providers.db.default_provider_id
}
 
# Create QBFT network
resource "chainlaunch_besu_network" "defi" {
  name         = "defi-network"
  description  = "DeFi consortium network"
  chain_id     = 1337
  consensus    = "qbft"
  block_period = 5
  epoch_length = 30000
  gas_limit    = 5000000
 
  initial_validator_key_ids = [
    for key in chainlaunch_key.validator : tonumber(key.id)
  ]
}
 
# Deploy validator nodes
resource "chainlaunch_besu_node" "validator" {
  count      = 4
  name       = "validator-${count.index}"
  network_id = tonumber(chainlaunch_besu_network.defi.id)
  key_id     = tonumber(chainlaunch_key.validator[count.index].id)
 
  mode    = "docker"
  version = "24.5.1"
 
  p2p_port = 30303 + count.index
  rpc_port = 8545 + count.index
 
  metrics_enabled  = true
  metrics_port     = 9545 + count.index
  metrics_protocol = "prometheus"
}

Four validators, QBFT consensus, Prometheus metrics — all in about 40 lines of HCL.

Which Key Management Backend Should You Use for Blockchain?

Every blockchain node needs cryptographic keys — and how you store those keys determines your security posture. According to Chainalysis, 43.8% of all stolen cryptocurrency in 2024 came from private key compromises, making key management the single largest attack vector in blockchain systems (Chainalysis, 2024). ChainLaunch's Terraform provider supports three cryptographic key backends: a built-in database provider requiring zero setup, AWS KMS for hardware-backed production keys with IAM role and STS AssumeRole authentication, and HashiCorp Vault for centralized secret management. The database provider supports all algorithms (RSA, EC with P-256/P-384/P-521/secp256k1, and ED25519), making it ideal for development and testing. AWS KMS adds hardware security module protection but doesn't support ED25519. Vault covers NIST curves but does not support the secp256k1 curve required for Besu validator keys. Choose based on your environment: database for dev, KMS for production Besu and Fabric, Vault for Fabric-only production with existing Vault infrastructure.

Database (Built-in, Zero Dependencies)

# The database provider ships with ChainLaunch — no setup required.
# It's the default provider, always available.
data "chainlaunch_key_providers" "default" {}
 
resource "chainlaunch_key" "fabric_key" {
  name        = "org1-signing-key"
  algorithm   = "EC"
  curve       = "P-256"
  provider_id = data.chainlaunch_key_providers.default.default_provider_id
}

AWS KMS (Hardware-Backed, Production)

resource "chainlaunch_key_provider" "kms" {
  name = "Production KMS"
  type = "AWS_KMS"
 
  aws_kms_config = {
    operation            = "IMPORT"
    aws_region           = "us-east-1"
    kms_key_alias_prefix = "chainlaunch/"
    # Uses IAM role — no static credentials needed
  }
}
 
resource "chainlaunch_key" "secure_key" {
  name        = "validator-key"
  algorithm   = "EC"
  curve       = "secp256k1"
  provider_id = tonumber(chainlaunch_key_provider.kms.id)
}

AWS KMS supports multiple auth modes: IAM instance roles (recommended), STS AssumeRole for cross-account setups, static credentials for development, and LocalStack for local testing.

HashiCorp Vault

resource "chainlaunch_key_provider" "vault" {
  name = "Vault"
  type = "VAULT"
 
  vault_config = {
    operation = "IMPORT"
    address   = "https://vault.example.com:8200"
    token     = var.vault_token
    mount     = "secret"
  }
}

One important caveat: Vault does not support the secp256k1 curve, so you can't use it for Besu validator keys. Use Database or AWS KMS for Ethereum-compatible keys.

{/* ============================================================ CHART 2: Key Provider Comparison (Grouped Bar / Matrix) ============================================================ */}

How Do You Deploy Fabric Chaincode with Terraform?

Hyperledger Fabric has over 500 production deployments worldwide, with roughly 40% market share among private ledger platforms (IDC, 2024). Yet Gartner estimates only 25% of Fabric proof-of-concepts reach production — and chaincode deployment complexity is a major reason why. The ChainLaunch Terraform provider models Fabric's entire chaincode lifecycle as six declarative resources — chaincode registration, version definition with Docker image and endorsement policy, peer installation, per-organization approval, channel commit, and container deployment — with Terraform automatically managing the correct dependency ordering between steps. Without IaC, deploying chaincode requires running peer lifecycle chaincode commands in a specific sequence across every organization in the network: package, install on each peer, approve from each org's admin, check commit readiness, commit to the channel, and then start the chaincode containers. Miss a step or run them out of order, and the deployment fails silently. With Terraform, you declare the desired end state and terraform apply handles the rest:

# 1. Register the chaincode
resource "chainlaunch_fabric_chaincode" "asset_tracker" {
  name       = "asset-tracker"
  network_id = chainlaunch_fabric_network.supply_chain.id
}
 
# 2. Define version, image, and endorsement policy
resource "chainlaunch_fabric_chaincode_definition" "v1" {
  chaincode_id       = chainlaunch_fabric_chaincode.asset_tracker.id
  version            = "1.0"
  sequence           = 1
  docker_image       = "myorg/asset-tracker:1.0"
  chaincode_address  = "asset-tracker.example.com:7052"
  endorsement_policy = "AND('Org1MSP.member','Org2MSP.member')"
}
 
# 3. Install on peers
resource "chainlaunch_fabric_chaincode_install" "install" {
  definition_id = chainlaunch_fabric_chaincode_definition.v1.id
  peer_ids      = [
    chainlaunch_fabric_peer.org1_peer0.id,
    chainlaunch_fabric_peer.org2_peer0.id
  ]
}
 
# 4. Approve per organization
resource "chainlaunch_fabric_chaincode_approve" "org1" {
  definition_id = chainlaunch_fabric_chaincode_definition.v1.id
  peer_id       = chainlaunch_fabric_peer.org1_peer0.id
  depends_on    = [chainlaunch_fabric_chaincode_install.install]
}
 
resource "chainlaunch_fabric_chaincode_approve" "org2" {
  definition_id = chainlaunch_fabric_chaincode_definition.v1.id
  peer_id       = chainlaunch_fabric_peer.org2_peer0.id
  depends_on    = [chainlaunch_fabric_chaincode_install.install]
}
 
# 5. Commit to channel
resource "chainlaunch_fabric_chaincode_commit" "commit" {
  definition_id = chainlaunch_fabric_chaincode_definition.v1.id
  peer_id       = chainlaunch_fabric_peer.org1_peer0.id
  depends_on    = [
    chainlaunch_fabric_chaincode_approve.org1,
    chainlaunch_fabric_chaincode_approve.org2
  ]
}
 
# 6. Deploy (start containers)
resource "chainlaunch_fabric_chaincode_deploy" "deploy" {
  definition_id = chainlaunch_fabric_chaincode_definition.v1.id
  depends_on    = [chainlaunch_fabric_chaincode_commit.commit]
}

Upgrading chaincode? Change the version, bump the sequence, and run terraform apply. Terraform handles the correct order of operations automatically.

How Do You Automate Blockchain Backups with Terraform?

A Unitrends survey of over 3,000 IT professionals found that only 35% of organizations can actually recover from downtime within hours, despite 60% believing they can (Unitrends, 2025). For blockchain networks, where ledger data represents immutable transaction history, unrecoverable data loss can mean losing the entire chain of trust. ChainLaunch's Terraform provider enables automated blockchain network backups through declarative resources supporting S3-compatible storage targets (AWS S3, MinIO), cron-based scheduling with configurable retention periods, and SMTP email notifications for backup failures and node downtime — all version-controlled alongside the network configuration. Most blockchain platforms leave backup management as an exercise for the operator, requiring custom scripts with restic or velero and manual cron jobs. The ChainLaunch provider treats backups as first-class infrastructure:

resource "chainlaunch_backup_target" "s3" {
  name              = "Production Backups"
  type              = "S3"
  region            = "us-west-2"
  access_key_id     = var.aws_access_key
  secret_access_key = var.aws_secret_key
  bucket_name       = "blockchain-backups"
  bucket_path       = "fabric-prod"
  restic_password   = var.backup_encryption_key
}
 
# Daily at 2 AM, keep 30 days
resource "chainlaunch_backup_schedule" "daily" {
  name            = "Daily Backup"
  target_id       = chainlaunch_backup_target.s3.id
  cron_expression = "0 2 * * *"
  enabled         = true
  retention_days  = 30
}
 
# Weekly on Sunday, keep 90 days
resource "chainlaunch_backup_schedule" "weekly" {
  name            = "Weekly Backup"
  target_id       = chainlaunch_backup_target.s3.id
  cron_expression = "0 3 * * 0"
  enabled         = true
  retention_days  = 90
}
 
# Get alerted when backups fail
resource "chainlaunch_notification_provider" "alerts" {
  name                  = "Ops Alerts"
  type                  = "SMTP"
  notify_backup_failure = true
  notify_node_downtime  = true
  is_default            = true
 
  smtp_config = {
    host       = "smtp.example.com"
    port       = 587
    from_email = "chainlaunch@example.com"
    to_email   = "ops@example.com"
    use_tls    = true
  }
}

Backups, retention, and alerting — all version-controlled alongside your network configuration.

How Does ChainLaunch Compare to Other Blockchain IaC Options?

About 117,000 companies use Terraform as their primary IaC tool (Enlyft, 2024). Yet the blockchain ecosystem has barely adopted it. Here's the landscape:

AWS Managed Blockchain has Terraform resources in the standard AWS provider (aws_managedblockchain_network, aws_managedblockchain_member, aws_managedblockchain_node), but coverage stops at basic provisioning. No channel management, no chaincode lifecycle, no key provider configuration.

Kaleido has a dedicated Terraform provider (registry.terraform.io/providers/kaleido-io/kaleido) that covers consortia, environments, and nodes. It's production-ready but SaaS-only — you can't self-host — and it doesn't expose key management or backup configuration.

Hyperledger Bevel uses Ansible playbooks and Helm charts, not Terraform. It's a fundamentally different approach — a deployment script generator rather than a declarative state manager.

Everyone else — Chainstack, Zeeve, BlockDaemon — either has no Terraform provider or relies on generic cloud infrastructure resources.

The gap is clear: while 90% of cloud infrastructure uses IaC practices, blockchain remains stuck in manual deployment mode. The enterprise blockchain market is projected to reach $287.8 billion by 2032 at 47.5% CAGR (Market Research Future, 2024). Teams that treat blockchain like any other infrastructure — version-controlled, peer-reviewed, reproducible — will move faster than those still running shell scripts.

How Do You Integrate Blockchain Terraform with CI/CD?

The CD Foundation's 2024 State of CI/CD Report, surveying over 125,000 developers, found that 83% are now involved in DevOps-related activities (CD Foundation, 2024). Because the ChainLaunch provider is standard Terraform, it plugs directly into existing CI/CD pipelines — GitHub Actions, GitLab CI, Jenkins, CircleCI, or ArgoCD — without requiring blockchain-specific tooling. This means blockchain infrastructure changes go through the same pull request review process as application code: a developer proposes a change, terraform plan shows exactly what will be created or modified, reviewers approve, and terraform apply executes the change. No more SSH-ing into servers to run ad-hoc commands. No more undocumented infrastructure drift. Here's a GitHub Actions example that deploys on push to main:

name: Deploy Blockchain Network
on:
  push:
    branches: [main]
    paths: ['infra/blockchain/**']
 
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
 
      - uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: 1.9.0
 
      - name: Terraform Init
        working-directory: infra/blockchain
        run: terraform init
 
      - name: Terraform Plan
        working-directory: infra/blockchain
        run: terraform plan -out=tfplan
        env:
          CHAINLAUNCH_URL: ${{ secrets.CHAINLAUNCH_URL }}
          CHAINLAUNCH_API_KEY: ${{ secrets.CHAINLAUNCH_API_KEY }}
 
      - name: Terraform Apply
        working-directory: infra/blockchain
        run: terraform apply -auto-approve tfplan
        env:
          CHAINLAUNCH_URL: ${{ secrets.CHAINLAUNCH_URL }}
          CHAINLAUNCH_API_KEY: ${{ secrets.CHAINLAUNCH_API_KEY }}

Push to main, and your blockchain network updates automatically. Every change is reviewed in terraform plan before it touches infrastructure.

How Do You Manage Multiple Blockchain Environments?

Most enterprise teams need at least three environments — development, staging, and production — with identical network topologies but different security configurations. With Terraform, this is solved through variable files: the same HCL code runs against different .tfvars files that control environment-specific settings like key provider type, Fabric version, and node sizing. Dev environments use the built-in database key provider for fast iteration with zero external dependencies. Production environments switch to AWS KMS for hardware-backed key storage with full audit logging. The network topology stays identical across environments, eliminating the "it worked in staging" problem that plagues manual deployments:

# variables.tf
variable "environment" {
  type = string
}
 
variable "fabric_version" {
  type    = string
  default = "2.5.0"
}
 
variable "key_provider_type" {
  type    = string
  default = "DATABASE"  # DATABASE for dev, AWS_KMS for prod
}
 
# Use different configs per environment
# terraform apply -var-file=environments/dev.tfvars
# terraform apply -var-file=environments/prod.tfvars

# environments/dev.tfvars
environment       = "dev"
fabric_version    = "2.5.0"
key_provider_type = "DATABASE"

# environments/prod.tfvars
environment       = "prod"
fabric_version    = "2.5.0"
key_provider_type = "AWS_KMS"

Same Terraform code, different variable files. Dev uses the built-in database for keys (fast, no dependencies). Production uses AWS KMS (hardware-backed, audit-logged). The network topology is identical — only the security posture changes.

How Do You Get Started?

Getting from zero to a running blockchain network takes four steps. First, install ChainLaunch on your server or local machine — it runs as a single binary with an embedded SQLite database, so there are no external dependencies. Second, add the kfsoftware/chainlaunch provider to your Terraform configuration. Third, pick one of the 31 ready-made examples covering Fabric multi-org networks, Besu QBFT clusters, AWS KMS key management, Vault integration, MinIO backups, plugin deployment, and more. Fourth, run terraform apply and watch your blockchain network come up in minutes instead of days.

1. Install ChainLaunch — docs.chainlaunch.dev/getting-started
2. Add the provider — source = "kfsoftware/chainlaunch" in your required_providers block
3. Pick an example from the 31 examples in the repo
4. Run terraform apply and your network is live

ChainLaunch is the unified control plane for enterprise blockchain infrastructure. Deploy Fabric and Besu networks, manage keys across providers, automate backups, and orchestrate multi-org networks — all through Terraform, REST API, or web UI. Get started free.

FAQ

Does the Terraform provider support both Fabric and Besu?

Yes. The provider has dedicated resource types for each platform. Fabric resources cover organizations, peers, orderers, channels, and the full chaincode lifecycle. Besu resources cover QBFT and IBFT2 networks with validator and full node deployment.

Can I use AWS KMS for key management?

Yes. Configure a chainlaunch_key_provider with type AWS_KMS and your keys are stored in hardware security modules. The provider supports IAM roles, STS AssumeRole, static credentials, and LocalStack for local testing.

How does it compare to Hyperledger Bevel?

Bevel generates Kubernetes manifests and Helm charts. It's a code generator, not a Terraform provider. ChainLaunch's Terraform provider manages the full lifecycle declaratively — create, update, and destroy resources through terraform apply with proper state tracking.

Can I import existing blockchain networks?

Yes. The chainlaunch_fabric_organization_import resource lets you import existing Fabric organizations with their crypto materials. Data sources let you reference existing networks, nodes, and keys without recreating them.

How many Terraform resources does ChainLaunch have?

The ChainLaunch Terraform provider includes 62 resources and 20 data sources. Resources cover Fabric organizations, peers, orderers, channels, the full 6-step chaincode lifecycle, Besu networks with QBFT and IBFT2 consensus, cryptographic key management across three backends (Database, AWS KMS, HashiCorp Vault), automated backups with S3-compatible storage, email notifications, plugin management, multi-instance network sharing, and remote SSH installation.

Can I deploy Hyperledger Fabric with Terraform?

Yes. The ChainLaunch Terraform provider is the only Terraform provider that covers the full Hyperledger Fabric lifecycle declaratively — from creating organizations and MSP identities, through deploying peer and orderer nodes, to forming channels, joining nodes, setting anchor peers, and running the complete chaincode lifecycle (define, install, approve, commit, deploy). All through terraform apply with proper state tracking and dependency resolution.

What consensus mechanisms does the ChainLaunch Terraform provider support?

The provider supports four consensus mechanisms across two blockchain platforms. For Hyperledger Fabric: etcdraft (the default Raft-based consensus) and smartbft (Byzantine fault tolerant consensus). For Hyperledger Besu: QBFT (Quorum Byzantine Fault Tolerant, recommended for new networks) and IBFT2 (Istanbul Byzantine Fault Tolerance 2.0). Consensus parameters like block period, epoch length, tick interval, and election tick are all configurable as Terraform attributes.

Is there a cost?

ChainLaunch core and the Terraform provider are open source. ChainLaunch Pro adds multi-instance collaboration, RBAC, OIDC/SSO, and automated backups scheduling with enterprise support.