Terraform

DockPod ships a Terraform provider — manage Git Deployment apps, custom domains, and provisioned databases declaratively, against the exact same REST API the web UI itself calls.

TIP

dockpod_deploy_app, dockpod_domain, dockpod_database, dockpod_database_link, and a dockpod_git_providers data source are all available. Full resource reference is on the Registry listing and in the provider's own repo.

1. Generate an API Key

Go to Settings → API Keys → Generate key, give it a name (e.g. "Terraform"), and copy the key immediately — it's shown only once, in the form dp_mcp_xxxxxxxxxxxxxxxxxxxx.

This is the same key type MCP clients use — it now also works as a plain Bearer token against DockPod's REST API directly, which is what the provider authenticates with.

2. Configure the Provider

terraform {
  required_providers {
    dockpod = {
      source = "hymns/dockpod"
    }
  }
}

provider "dockpod" {
  host    = "https://your-server:8080" # or set DOCKPOD_HOST
  api_key = var.dockpod_api_key        # or set DOCKPOD_API_KEY
}

host/api_key can come from the provider block or the DOCKPOD_HOST/DOCKPOD_API_KEY environment variables — useful in CI, where committing either value into a .tf file isn't desirable.

3. Declare an App

resource "dockpod_deploy_app" "api" {
  name        = "my-api"
  repo_url    = "https://github.com/you/my-api.git"
  branch      = "main"
  deploy_type = "dockerfile"

  env_vars = {
    NODE_ENV = "production"
  }
}

terraform apply manages the app's configuration only — repo, branch, build type, env vars. It never triggers a build itself. The first deploy (and every one after) happens exactly how it already does outside Terraform: a push to the branch fires the webhook DockPod registers automatically, or you trigger one manually from the web UI, MCP, or DockPod's own API. An apply that only touches config shouldn't have a build — and the container swap that comes with it — as a surprise side effect.

If a Git provider is already connected under Settings → Git Providers, reference it by ID instead of a raw repo_url — this authenticates over the provider's own credentials (no SSH deploy key to manage), and for a GitHub App provider, push-to-deploy works immediately with no extra webhook setup:

resource "dockpod_deploy_app" "api" {
  name            = "my-api"
  git_provider_id = "<id from Settings -> Git Providers>"
  repo_full_name  = "you/my-api"
  branch          = "main"
  deploy_type     = "dockerfile"
}

4. Add a Domain and a Database

resource "dockpod_domain" "api" {
  deploy_app_id  = dockpod_deploy_app.api.id
  domain         = "api.example.com"
  container_port = 3000
}

resource "dockpod_database" "cache" {
  name = "my-api-cache"
  type = "redis"
}

resource "dockpod_database_link" "cache" {
  deploy_app_id = dockpod_deploy_app.api.id
  database_id   = dockpod_database.cache.id
  env_prefix    = "CACHE"
}

Neither dockpod_domain nor dockpod_database has an update endpoint on DockPod's side, so every attribute on those two (and on dockpod_database_link) forces a replace rather than an in-place change.

Full resource reference — including the dockpod_git_providers data source, every attribute, and import support — is on the Registry listing and in the provider's own repo.