Managed Temporal

Managed Temporal workflow engines for durable workflows: a local dev server with specific dev, and an auto-provisioned Temporal Cloud namespace in production.

Define managed Temporal workflow engines for durable workflows, background tasks, AI agents, batch jobs, and more. One temporal block gives you a local Temporal server in development and a Temporal Cloud namespace in production, with credentials wired into your services automatically. There is no server to install, host, or upgrade in either environment.

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

These can be used in service env blocks, both standalone and inside interpolated strings.

Because your code only reads these environment variables, the same worker and client code runs unchanged against the local dev server and Temporal Cloud. There are no environment-specific overrides to maintain.

Running Temporal locally

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.

There is nothing to install or start manually, and no Docker involved. Workflow data persists across dev server restarts in a SQLite database under .specific/keys/<key>/data/, so in-flight workflows and history survive stopping and restarting specific dev.

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. You don’t need a Temporal Cloud account, and the operational side of Temporal (running and upgrading the server, managing its persistence, sizing the cluster) is handled for you.

Workflow history retention

Specific configures closed workflow history retention from your plan:

• Free: 1 day
• Pro: 7 days
• Scale and Startup: 30 days
• Enterprise: configurable from 1 to 90 days

Retention starts when a workflow execution closes. Running workflows are not removed by this policy. When your plan changes, the new retention applies to workflows that close after the change; already-closed workflows keep the policy that was active when they closed. Increasing retention cannot restore history that Temporal has already deleted.

Workers

Temporal workers are regular service blocks: they get a build, a command, and whatever references they need. A typical worker has no public endpoint, so it can reach Temporal, your database, and storage without being reachable from the internet. Other services dispatch workflows through the same temporal.<name>.* references; the worker picks them up.

Their production replica policy is dashboard-managed and visible read-only in specific status.

Monitoring workflows

In development, the Temporal Web UI is embedded in the local dashboard, next to your services’ logs and database. In production, workflow monitoring is available through the Specific dashboard.

Common questions

Do I need a Temporal Cloud account?

No. Specific provisions and manages the Temporal Cloud namespace, service account, and API key as part of specific deploy. You never touch Temporal Cloud’s console.

Which languages can I use?

Any language with a Temporal SDK: TypeScript, Python, Go, Java, .NET, and PHP. The Specific integration only supplies the address, namespace, and API key; your workflow and activity code is standard Temporal.

Can I run more than one Temporal engine?

Yes. Each temporal block gets its own namespace: on the shared local dev server in development, and as a separate managed Temporal Cloud namespace in production.

When should I use a cron instead?

When the job is a single command on a schedule, use the built-in cron block; it needs no persistent worker. Use Temporal when workflows are multi-step, long-running, or need durable retries and state.