ngrok's new Terraform provider

One of the more common questions I’ve fielded over the past year is some version of this: “I’m trying to manage my ngrok infrastructure with Terraform and the provider doesn’t have half the resources I need—what’s going on here?”

The rebuilt ngrok Terraform provider is live today as v0.8.1. Here’s what you can do with it.

Bookmark this sectionBuilt for production workflows

Managing ngrok through the dashboard works fine when you’re one person with two tunnels. Once you’re running dozens of endpoints across staging and production, with access policies to keep consistent, credentials for multiple teams, and new services onboarding every week, you want your ngrok setup in version control like any other infrastructure.

The provider makes that workflow real. Every resource is declarative, importable, and reviewable. Your domains, cloud endpoints, access policies, and credentials live in the same repo as your services. Changes go through PR review. Rollbacks are a git revert. New teammates get access by reading config, not by asking whoever set things up originally. Every resource also has a corresponding data source, so shared modules can reference existing ngrok infrastructure without pulling it into state.

Bookmark this sectionCloud endpoints with Traffic Policy

Cloud Endpoints are ngrok-hosted entry points for traffic to your services, and they’re where most of the production value is. Pair them with Traffic Policy and you control exactly what reaches your upstream: authentication, rate limiting, header manipulation, and routing, all declaratively and in code.

Here’s a cloud endpoint that gates traffic behind Google OAuth, allows only your company’s email domain through, and rate-limits by IP:

1resource "ngrok_domain" "api" {2  domain      = "api.example.com"3  description = "Production API"4}56resource "ngrok_cloud_endpoint" "api" {7  url         = "https://${ngrok_domain.api.domain}"8  description = "Production API endpoint"910  traffic_policy = jsonencode({11    on_http_request = [12      {13        name = "RateLimit"14        actions = [{15          type = "rate-limit"16          config = {17            name       = "per-ip"18            algorithm  = "sliding_window"19            capacity   = 10020            rate       = "60s"21            bucket_key = ["conn.client_ip"]22          }23        }]24      },25      {26        name = "RequireAuth"27        actions = [{28          type   = "oauth"29          config = { provider = "google" }30        }]31      },32      {33        name        = "RestrictEmails"34        expressions = ["!actions.ngrok.oauth.identity.email.endsWith('@example.com')"]35        actions = [{36          type   = "deny"37          config = { status_code = 403 }38        }]39      }40    ]41  })42}

The RestrictEmails rule uses a Traffic Policy expression to deny anyone who authenticates with an email outside your domain, so a Google login alone isn’t enough to get through.

Apply this pattern across ten endpoints and every one gets the same policy, enforced consistently. Someone forgets to add OAuth to a new service? The PR reviewer catches it, not a security audit six months later. Traffic Policy also supports JWT verification, custom response headers, IP restrictions, and request routing, all composable in the same block.

Bookmark this sectionCredential management that doesn’t live in Slack

Most teams end up storing ngrok API keys in someone’s notes or a shared Slack DM. ngrok_vault and ngrok_secret make credentials first-class Terraform resources:

1resource "ngrok_vault" "prod" {2  name        = "production"3  description = "Production credential store"4}56resource "ngrok_secret" "api_key" {7  vault_id = ngrok_vault.prod.id8  name     = "api-key"9  value    = var.api_key10}

Reference them across resources the same way you’d reference any other Terraform output, with no out-of-band secrets to pass around and nothing to synchronize by hand between environments.

Bookmark this sectionBring your existing infrastructure under management

If you’re already running ngrok in production, you don’t have to start from scratch. Every resource supports terraform import. Run it against existing domains and endpoints, and they’re in state.

terraform import ngrok_domain.api <DOMAIN_ID>

For teams with dozens of domains already provisioned, this is the difference between “we can adopt Terraform” and “we’d have to redo everything first.”

Bookmark this sectionGet started

1terraform {2  required_providers {3    ngrok = {4      source  = "ngrok/ngrok"5      version = "~> 0.8.1"6    }7  }8}910provider "ngrok" {11  api_key = var.ngrok_api_key  # or set NGROK_API_KEY12}

The provider documentation covers every resource and data source with examples. For teams already running ngrok at scale, start with terraform import: it’s the fastest path to management without reprovisioning anything that’s already running.

Still have questions? Email me directly and I’ll get you set up for your use case.