Terraform provider: devflow_monitor, devflow_slo, devflow_channel
Owner Theo Hayashi · Last updated 2026-04-12 · v3.5
terraformiachclproviderdeclarative
Terraform provider
The Terraform provider is the way most engineering teams manage DevFlow at scale. Declarative, version-controlled, reviewable.
install
hcl
terraform {
required_providers {
devflow = {
source = "devflow-io/devflow"
version = "~> 2.0"
}
}
}
provider "devflow" {
api_key = var.devflow_api_key
workspace = "acme-prod"
}The provider is published to the official Terraform Registry.
a monitor
hcl
resource "devflow_monitor" "payments_charge" {
name = "payments-api-charge"
url = "https://api.example.com/v1/charges"
method = "POST"
frequency = "30s"
regions = ["us-east-1", "eu-west-1"]
assertions {
type = "status_eq"
value = 200
}
assertions {
type = "latency_lt_ms"
value = 800
}
alert_channel_ids = [devflow_channel.payments_oncall.id]
}an SLO
hcl
resource "devflow_slo" "payments_availability" {
name = "payments-availability-99.9"
target = 0.999
window = "28d"
source_monitor = devflow_monitor.payments_charge.id
}a channel
hcl
resource "devflow_channel" "payments_oncall" {
type = "pagerduty"
name = "payments-oncall"
routing_key = var.pagerduty_routing_key
}state
We do not have any opinion on where you store your Terraform state. S3 + DynamoDB-lock is a fine default.
CI
A common pattern: PR opened → terraform plan runs in CI against a service-account key with monitor:write (rest-api-authentication) → human reviews → merge → terraform apply on main.
drift detection
Run terraform plan on a schedule (we recommend daily) to catch dashboard-level drift. Many teams refuse the dashboard for changes — Terraform-only.
versioning
Provider releases follow rest-api-overview versioning conventions. Breaking changes are major bumps with deprecation notice.