Temporal is the workflow engine of choice for durable execution: code that survives crashes, retries automatically, and can sleep for days in the middle of a function. Payments, AI agent loops, provisioning pipelines. Once you've used it, going back to hand-rolled queues and retry logic feels primitive.

But there's a gap between "Temporal is great" and "Temporal is running in production." This post covers what hosting Temporal actually involves, what your options are, and how we've made managed Temporal a single block of configuration in Specific.

What self-hosting Temporal involves

The Temporal server is not a single binary you drop on a box (the dev server is, more on that below, but it's explicitly not for production). A production deployment means:

Four server services: frontend, history, matching, and worker, usually run as separate scaled deployments.
A persistence layer: PostgreSQL, MySQL, or Cassandra for workflow state and history.
Visibility storage: the store that powers workflow search. Postgres or MySQL can serve it at modest scale; Temporal recommends Elasticsearch for anything beyond a small volume of workflows.
Upgrades and schema migrations: releases ship database schema changes applied with Temporal's schema tools, and the server must be upgraded sequentially, one minor version at a time.
Capacity planning: history shards are fixed at cluster creation, so you have to size the cluster for future load on day one.

None of this is your application. It's undifferentiated infrastructure between you and the thing you wanted: durable workflows.

The managed options

Temporal Cloud is the official managed service, run by the team behind Temporal. It removes the entire server-side burden, and it's what we build on. Using it directly still leaves integration work on your plate though: creating namespaces per environment, provisioning service accounts and API keys, distributing those credentials to your services, and standing up somewhere to run your workers. Your local dev setup remains separate from all of it.

Specific manages both sides. The Temporal namespace in production, the dev server locally, and the workers that connect to them, all from one config file.

Managed Temporal in one config block

Here's a complete setup in Specific: a Temporal engine and a worker service that connects to it.

temporal "jobs" {}

build "worker" {
  base    = "node"
  command = "npm run build"
}

service "worker" {
  build   = build.worker
  command = "node dist/worker.js"

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

  dev {
    command = "npm run worker:dev"
  }
}

The temporal "jobs" {} block is the whole engine definition. The three references in env resolve to the right values in every environment, so your worker code reads plain environment variables and never knows the difference.

In local development, specific dev downloads the Temporal CLI on first run, starts a dev server with persistent storage, and puts the Temporal Web UI in your local dashboard. Workflow state survives restarts.

In production, specific deploy provisions a dedicated Temporal Cloud namespace, creates a service account with write access, generates an API key, and injects the credentials into your services. No dashboard visits, no credential copy-pasting, no environment-specific config.

Your worker is a regular service on the same platform as the rest of your app, deployed in the same pipeline. If it needs the database or object storage, those are references in the same file.

What you still own

Specific manages the engine, not your code. You write workflows and activities with the standard Temporal SDKs (TypeScript, Python, Go, Java, .NET, PHP), and everything in the Temporal docs applies unchanged. If you later outgrow the managed setup, your workflow code is portable: it's standard Temporal, pointed at a different address.

If all you need is "run this command every night", you don't need Temporal at all. Specific has a built-in cron block for one-off scheduled jobs. Reach for Temporal when workflows are multi-step, long-running, or need durable retries.

Common questions

Do I need a Temporal Cloud account?

No. Specific provisions and manages the Temporal Cloud namespace for you as part of specific deploy. You never touch Temporal Cloud's console.

Can my agent set this up?

That's the point of Specific: the config file above is exactly what coding agents are good at writing. Claude Code, Cursor, or Codex can add the temporal block, wire the env vars, scaffold the worker, and validate everything with specific check.

How do I see what my workflows are doing?

Locally, the Temporal Web UI is embedded in the local dashboard that specific dev serves. In production, workflow monitoring is available through the Specific dashboard.

Try it

We have a complete working example: a task queue app with a live demo, showing workflows, activities, and a worker service end to end. Read the walkthrough, try the live demo, or browse the source.

To start in your own project, give your agent this prompt:

Help me get started with Specific by following: https://docs.specific.dev/for-ai/onboarding

Or install the CLI yourself:

curl -fsSL https://specific.dev/install.sh | sh

Then run specific init and ask your agent for durable workflows.

For more depth, see the Temporal guide in our docs, how to run Temporal locally, and our explainer on what durable execution is.