Skip to content
Specific Docs
Esc
navigateopen⌘Jpreview
On this page

Temporal

Managed Temporal workflow engines for durable workflows and background tasks.

Define managed Temporal workflow engines for durable workflows, background tasks, AI agents, batch jobs, and more.

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:

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

Attribute Description Dev value Production value
temporal.<name>.url gRPC address of the Temporal server localhost:<port> Temporal Cloud gRPC address
temporal.<name>.namespace Temporal namespace default Managed namespace ID
temporal.<name>.api_key API 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.

Was this page helpful?