Skip to main content
Define managed Temporal workflow engines for durable workflows, background tasks, AI agents, batch jobs, and more.
To simply run a command on a schedule, prefer the built-in cron block. Each run is a one-off job, so there’s no persistent worker to keep running. Reach for Temporal’s own schedule support when you need complex or long-running scheduled workflows (durable, multi-step, with retries), or when you already run a Temporal worker.
Temporal has SDKs for TypeScript, Python, Go, Java, .NET, and PHP. See the Temporal documentation for language-specific guides on workers, workflows, and activities. This page covers the Specific integration.

​
Configuration

Define a temporal block and reference it from services:
specific.hcl
temporal "tasks" {}

build "app" {
  base = "node"
}

service "worker" {
  build   = build.app
  command = "node worker.js"

  env = {
    TEMPORAL_ADDRESS   = temporal.tasks.url
    TEMPORAL_NAMESPACE = temporal.tasks.namespace
    TEMPORAL_API_KEY   = temporal.tasks.api_key
  }

  dev {
    command = "node --watch worker.js"
  }
}

​
Reference attributes

AttributeDescriptionDev valueProduction value
temporal.<name>.urlgRPC address of the Temporal serverlocalhost:<port>Temporal Cloud gRPC address
temporal.<name>.namespaceTemporal namespacedefaultManaged namespace ID
temporal.<name>.api_keyAPI key for authentication"" (empty, no auth in dev)Auto-generated API key
These can be used in service env blocks, both standalone and inside interpolated strings.

​
Local development

Running specific dev automatically:
  1. Downloads the Temporal CLI (first run only).
  2. Starts a Temporal dev server with persistent storage.
  3. Makes the Temporal Web UI available in the local dashboard sidebar under Workflows.
Workflow data persists across dev server restarts in a SQLite database under .specific/keys/<key>/data/. The api_key attribute is an empty string in dev since the Temporal dev server doesn’t require authentication. This is safe: Temporal SDKs apply authentication only when a non-empty key is provided.

​
Production

Running specific deploy automatically provisions a managed Temporal Cloud namespace for each temporal block, with no manual setup:
  1. A dedicated Temporal Cloud namespace is created.
  2. A service account with write access is provisioned.
  3. An API key is generated for authentication.
  4. Credentials are securely injected into your services.
The same references resolve to the Temporal Cloud values in production, so no environment-specific overrides are needed.