TigerData: can I provision and manage Tiger Cloud with Terraform/CLI, and where are the examples?

Most Tiger Cloud teams want automation from day one: provision services in code, resize or fork without clicking through a UI, and wire everything into CI/CD. You can do all of that today with TigerData using the Tiger CLI, Tiger MCP (for AI-assisted workflows), and emerging Terraform-style infrastructure-as-code (IaC) patterns.

This guide walks through what’s available, how it works, and where to find concrete, copy‑pasteable examples.

Quick Answer: Yes, you can provision and manage Tiger Cloud via CLI and API-like workflows today, and you can wrap those in Terraform or other IaC tools. The official starting points are the Tiger CLI docs, Tiger MCP tools list, and example scripts in TigerData’s GitHub and docs.

The Quick Overview

What It Is: Programmatic control of Tiger Cloud—creating, resizing, forking, and managing Postgres + TimescaleDB services—via CLI and AI-assisted commands, with patterns that map cleanly to Terraform and other IaC tools.
Who It Is For: Platform teams, SREs, and developers who want to treat Tiger Cloud as code: reproducible environments, CI/CD integration, and automated lifecycle management.
Core Problem Solved: Manual, click-heavy workflows in a web UI don’t scale. You need a reliable way to spin up and manage telemetry-grade Postgres (with TimescaleDB) across dev, staging, and prod, without fragile scripts or copy‑pasted configuration.

How It Works

At its core, Tiger Cloud exposes all of its database lifecycle operations—create, resize, fork, start/stop, manage passwords, run SQL—through a programmatic interface. You access that interface via:

Tiger CLI: A command-line tool that authenticates against your Tiger Cloud account and lets you manage services directly from your terminal or CI.
Tiger MCP: A Model Context Protocol server that exposes Tiger Cloud management tools to your AI Assistant, so you can issue natural-language commands and let the MCP tools translate those into service operations.
APIs-under-the-hood: The CLI and MCP tools call the same underlying APIs. Terraform and other IaC workflows typically shell out to the CLI or call these APIs directly.

A pragmatic setup usually looks like:

Local + CI/automation via Tiger CLI
Install the CLI, configure authentication, and use CLI commands in scripts or CI pipelines to create services, resize plans, set passwords, and run migrations.
AI-assisted operations via Tiger MCP
Enable the Tiger MCP server for your AI Assistant. From there, you can ask things like “Create a new Tiger Cloud service for staging with the same size as prod” and the MCP tools will handle the low-level calls.
Terraform / IaC integration via CLI wrappers
Wrap CLI commands in Terraform null_resource/local-exec blocks or custom providers/modules so your Tiger Cloud resources are declared and tracked alongside the rest of your infrastructure.

1. Tiger CLI: Core Primitive for Automation

Tiger CLI is the primary way to script Tiger Cloud operations.

With the CLI you can:

List, create, fork, start, stop, and resize database services
View service details and logs
Update passwords and credentials
Execute SQL against your Tiger Cloud databases
Inspect performance, query metrics, and more via Tiger Console in parallel

A typical workflow might be:

Install the CLI
(Refer to the official TigerData docs for OS-specific install commands.)
Authenticate securely
You configure the CLI with your Tiger Cloud credentials (and, ideally, multi‑factor authentication on your account). This gives your local environment or CI runner scoped access to your Tiger services.

Script lifecycle operations
For example:

# Pseudocode-style CLI examples – check docs for exact commands/flags

# Create a new service
tiger services create \
  --name myapp-staging \
  --plan performance-2 \
  --region us-east-1

# Resize a service
tiger services resize \
  --service myapp-staging \
  --plan performance-4

# Fork production into a staging clone
tiger services fork \
  --source myapp-prod \
  --target myapp-staging-clone

# Rotate a database password
tiger services password rotate \
  --service myapp-prod

Wire into CI/CD
Add these commands to your pipeline (GitHub Actions, GitLab CI, Jenkins, etc.) so that environments are created, migrated, and retired automatically.

Note: Always treat CLI credentials as secrets. Use your CI’s secrets manager and avoid checking any tokens into version control.

2. Tiger MCP: AI-Assisted Tiger Cloud Management

Tiger MCP is a Model Context Protocol server that exposes Tiger Cloud management tools to your AI Assistant.

Once configured, your assistant can confirm:

“Yes, the Tiger MCP server is active! I have access to a comprehensive set of Tiger Cloud (Timescale) tools, including:
Service Management: list, create, fork, start, stop, and resize database services; view service details and logs; update passwords.
Database Operations: execute SQL queries against…”

From there you can issue natural-language commands:

“Create a new Tiger Cloud service named iot-dev in us-east-1 with a small performance plan.”
“Fork myapp-prod to myapp-debug and give me a connection string.”
“Run SELECT count(*) FROM telemetry.hypertable_stats; on myapp-prod and summarize the output.”

Under the hood, MCP calls the same service management APIs as the CLI. The difference is:

CLI: best for deterministic, repeatable scripts and CI.
MCP: best for exploratory work, debugging, and ad‑hoc operations from your AI Assistant.

3. Terraform & IaC Patterns with TigerData

There are two common ways teams integrate Tiger Cloud with Terraform or other IaC tools today:

Pattern A: Shelling out to Tiger CLI (Fastest to Adopt)

This pattern uses Terraform’s null_resource and local-exec to treat Tiger services as managed external resources.

Example (conceptual):

resource "null_resource" "tiger_myapp_staging" {
  triggers = {
    name  = "myapp-staging"
    plan  = "performance-2"
    region = "us-east-1"
  }

  provisioner "local-exec" {
    command = <<EOT
      tiger services create \
        --name ${self.triggers.name} \
        --plan ${self.triggers.plan} \
        --region ${self.triggers.region} || \
      tiger services resize \
        --service ${self.triggers.name} \
        --plan ${self.triggers.plan}
    EOT
  }
}

You can refine this with:

Separate resources for create vs resize
data blocks that call CLI to read service state (e.g., connection URLs)
Outputs exporting service host/port/database/user for app modules

Pros:

No custom provider required
Uses the same CLI you already trust
Easy to experiment with locally

Cons:

Terraform cannot natively “diff” Tiger resources—it relies on triggers and scripts
Error handling is your responsibility in the shell scripts

Pattern B: Custom Terraform Provider or Reusable Modules

Some teams package Tiger Cloud operations into:

A custom Terraform provider that calls the same underlying Tiger Cloud APIs that the CLI uses.
A set of Terraform modules that standardize service naming, plans, networking, and outputs across environments.

In either case, the internal logic is still based on the same service controls:

create, fork, start, stop, resize
update passwords
execute SQL for bootstrap tasks (e.g., creating hypertables, enabling compression, adding continuous aggregates)

Important: If you build a custom provider, follow TigerData’s authentication and permission model. Use API tokens or service accounts scoped to the minimal set of Tiger Cloud operations needed for your Terraform runs.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Tiger CLI	Command-line access to all Tiger Cloud service management operations	Scriptable, CI-friendly control of Postgres + Timescale
Tiger MCP tools	Exposes Tiger Cloud management and SQL execution to your AI Assistant	Natural-language operations and diagnostics
IaC-friendly design	CLI/API abstractions that map cleanly to Terraform and other IaC workflows	Reproducible, versioned infrastructure management

Ideal Use Cases

Best for Postgres platform teams: Because you can treat Tiger Cloud as a first-class resource in your infra code, with clear service boundaries (one database per service), HA, and telemetry-ready primitives built in.
Best for telemetry-heavy applications: Because Tiger Cloud (Postgres + TimescaleDB) handles time-series, events, and vector workloads, and the CLI/MCP stack lets you spin up specialized services (e.g., “analytics”, “archive”) without manual UI work.

Limitations & Considerations

Terraform state vs Tiger state:
When using CLI-based Terraform patterns, Terraform doesn’t inherently know about Tiger Cloud service state. You must design your triggers, naming conventions, and scripts carefully to avoid drift.
Credential management:
CLI and MCP access to Tiger Cloud is powerful. Use MFA on your Tiger Cloud account, store tokens in secure secret managers, and follow least-privilege practices for automation.

Pricing & Plans

Using CLI, MCP, or Terraform-style workflows does not change your Tiger Cloud pricing model. You:

Pay for the underlying Tiger Cloud service plans you select (e.g., Performance, Scale, Enterprise tiers).
Do not pay extra per query or for automated backups—TigerData emphasizes transparent, usage‑based billing.
Can independently scale compute and storage on Tiger Cloud plans, add HA and replicas, and track costs in Tiger Console.

A common mapping:

Performance Plan: Best for developers and teams needing fast, cost-effective services for dev/staging and many production workloads.
Scale / Enterprise Plans: Best for high-ingest telemetry, regulated environments, and workloads needing features like multi‑AZ HA, HIPAA (Enterprise), SOC 2 Type II, and 24/7 support with SLAs.

Frequently Asked Questions

Can I fully manage Tiger Cloud with Terraform alone?

Short Answer: You can manage Tiger Cloud from Terraform today by wrapping the Tiger CLI or calling the same APIs, and many teams do this in practice.

Details:
TigerData’s primary automation surfaces are the CLI and MCP tools. Terraform and other IaC systems integrate by:

Shelling out to tiger CLI in local-exec provisioners
Or using custom providers/modules that call the same service APIs

This gives you “Terraform as control plane,” while still relying on Tiger Cloud’s native primitives for service lifecycle, HA, backups, and telemetry features. Always ensure your Terraform roles have the minimal Tiger Cloud permissions required, and test stateful operations (resizes/forks) in non‑prod first.

Where can I find working examples of CLI or IaC workflows?

Short Answer: Start with the Tiger CLI and Tiger MCP sections of the official TigerData docs, and look for example scripts and configuration in TigerData’s GitHub repositories.

Details:
TigerData’s documentation includes:

Installation and authentication steps for Tiger CLI
A list of service management commands (create, fork, resize, start/stop, logs, passwords)
Tiger MCP configuration and the exact tools exposed to your AI Assistant

For IaC inspiration, you’ll find:

Example shell scripts in docs or GitHub that show how to use CLI to create and manage services
Community patterns that wrap the CLI in Terraform local-exec blocks or custom providers
Example SQL that you can run via CLI or MCP (CREATE EXTENSION timescaledb;, creating hypertables, add_continuous_aggregate_policy, etc.)

If you’re unsure whether a specific Terraform pattern is safe or recommended, a good workflow is:

Prototype the operation via Tiger CLI.
Ask your AI Assistant (with Tiger MCP enabled) to generate a Terraform wrapper.
Test in a non‑production Tiger Cloud service before promoting to your main IaC repo.

Summary

You can absolutely provision and manage Tiger Cloud programmatically—with Tiger CLI as the core primitive, Tiger MCP for AI-assisted workflows, and Terraform or other IaC tools layered on top. The same operations you’d click through in Tiger Console—create, fork, resize, start/stop, password management, SQL execution—are all available from the command line and via MCP tools.

By treating Tiger Cloud as code, you get:

Reproducible environments for dev, staging, and prod
Safe, automated resizes and forks
Postgres + TimescaleDB telemetry primitives (hypertables, compression, continuous aggregates) wired into your deployment pipelines

All while keeping Postgres as your foundation and avoiding the “fragile and high-maintenance” multi-system pipelines that TigerData is designed to replace.

Next Step

Get Started