How do we get started with Temporal locally (dev server) and then deploy workers to Kubernetes?

What if you could crash your laptop, restart Docker, or roll a cluster—and your long-running business logic just kept going? That’s the point of starting Temporal locally first: prove to yourself that failures don’t matter, then move that same code into Kubernetes without rewriting a giant state machine.

Quick Answer: Run temporal server start-dev with the Temporal CLI to get a local dev server and Web UI, build and run your Worker against that dev namespace, then containerize the Worker and deploy it into Kubernetes while pointing it at a production Temporal Service (self-hosted or Temporal Cloud).

Frequently Asked Questions

How do I get started with Temporal locally using the dev server?

Short Answer: Install Temporal CLI, run temporal server start-dev, pick an SDK, run a sample Workflow, and inspect it in the Web UI at http://127.0.0.1:8233.

Expanded Explanation:
Temporal’s local dev story is intentionally simple. You don’t start by wiring up a database or a cluster. You start by running a single command that spins up a Temporal Service, persistence, and the Web UI, all on your laptop. Then you write a Workflow and a Worker in your preferred SDK (Go, Java, TypeScript, Python, .NET), point the Worker at localhost, and watch Temporal keep your code alive through crashes, retries, and timeouts.

The local dev server is not a toy—it uses the same Durable Execution semantics as production: event histories, deterministic replay, task queues, signals, timers, and visibility. The key difference is that it’s optimized for ease-of-use, not for multi-tenant scale or high-availability. You use it to iterate on your Workflow definitions and Activity implementations before worrying about Kubernetes, Helm charts, or multi-region deployments.

Key Takeaways:

• Install Temporal CLI, then start the dev server with temporal server start-dev.
• Point your Worker code at the local server, run a sample Workflow, and inspect it via the Temporal Web UI at http://127.0.0.1:8233.

---

What are the exact steps to run Temporal locally and then deploy Workers to Kubernetes?

Short Answer: First, develop against temporal server start-dev on your laptop; once your Workflows are stable, containerize the Worker process and deploy it as a Kubernetes Deployment that connects to a production Temporal Service endpoint.

Expanded Explanation:
Without Temporal, you typically “develop locally” by mocking everything or by wiring your code directly to test databases and queues. With Temporal, you get a self-contained dev server that behaves like a single-node Temporal cluster. You build and debug your Workflows against this dev server, then move only your Worker process into Kubernetes while pointing it at the right Temporal Service address and TLS configuration.

The Temporal Service itself can be self-hosted in Kubernetes or consumed via Temporal Cloud. Either way, your Workers (your code) stay in your environment. Temporal never runs your code; the Service only coordinates execution via task queues, histories, and commands. The process is:

1. Prove your logic locally against start-dev.
2. Build a Docker image for your Worker.
3. Deploy the Worker image as a Kubernetes Deployment that connects to a real Temporal namespace.

Steps:

1. Set up local dev:

   • Install Temporal CLI (for example on macOS):

     brew install temporal
     

   • Start the dev server:

     temporal server start-dev
     

   • Open the Web UI at http://127.0.0.1:8233.

2. Build and run your Worker locally:

   • Choose an SDK (Go, Java, TypeScript, Python, .NET).
   • Implement a Workflow (durable code) and Activities (failure-prone operations).
   • Configure the SDK client to talk to localhost:7233 (default dev server port).
   • Run your Worker process locally and kick off a Workflow Execution.
   • Kill the Worker mid-flight, restart it, and observe the Workflow resume from history.

3. Containerize and deploy your Worker to Kubernetes:

   • Create a Dockerfile that:
     • Copies your Worker code.
     • Installs dependencies.
     • Sets the entrypoint to start the Worker process.
   • Push the image to your registry.
   • Create a Kubernetes Deployment and ServiceAccount (if needed) for the Worker.
   • Update the Worker config to point the Temporal client at your production Temporal Service or Temporal Cloud endpoint with appropriate namespace and TLS.
   • kubectl apply the manifests and use the Temporal Web UI (for that cluster/Cloud namespace) to observe running Workflows.

---

What’s the difference between the Temporal dev server and a production Temporal deployment?

Short Answer: The dev server is a single-node, “batteries-included” instance for local development; production deployments (self-hosted or Temporal Cloud) are multi-component, scalable, and designed for high availability and multi-tenant use.

Expanded Explanation:
The dev server (temporal server start-dev) trades robustness and scale for convenience. It bundles the Temporal Frontend, history, matching, persistence, and UI into a single process. It uses in-memory or local storage and default configuration. You can reset namespaces and histories at will. This is ideal for iterating on code but not something you’d run in front of customer traffic.

Production Temporal is different. You typically deploy multiple Temporal Services behind load balancers, backed by replicated databases and queues. You tune retention, namespaces, and worker QPS. In Temporal Cloud, we run all of this for you: multi-region, autoscaled, hardened; you just point your Workers at a public endpoint and get a logically isolated namespace. Either way, the dev vs. prod split is clear: same programming model, different operational posture.

Comparison Snapshot:

• Dev server (start-dev): Single process, local storage, fast setup, easy resets; perfect for experimentation and testing.
• Production (self-hosted or Cloud): Multi-service, scalable, HA, tuned for durability and throughput; designed for real workloads and SLAs.
• Best for: Use start-dev for development and local testing; use a production Temporal cluster or Temporal Cloud for staging and production namespaces.

---

How do I implement and run Workers in Kubernetes with a Temporal Service?

Short Answer: Build a Dockerized Worker that uses a Temporal SDK client configured for your production namespace, then deploy it as a Kubernetes Deployment that polls Temporal task queues and executes Activities and Workflows.

Expanded Explanation:
Temporal splits responsibilities: the Service persists history and coordinates execution; your Workers run your code. In Kubernetes, Workers are just regular pods that maintain long-lived gRPC connections to the Temporal Service and poll task queues. When a Workflow needs Activity execution or replay, the Service hands a task to a Worker through these queues. If the Worker crashes or a pod gets rescheduled, another Worker picks up the task, replays history if needed, and continues.

Your main implementation tasks are:

• Packaging the Worker application.
• Configuring connection settings (host, port, TLS, namespace, queue names).
• Ensuring Kubernetes liveness/readiness probes don’t thrash your Workers.
• Scaling replicas based on queue throughput and latency goals.

What You Need:

• A Worker binary or runtime with:
  • Workflow registrations (e.g., worker.registerWorkflow(MyWorkflow)).
  • Activity registrations (e.g., worker.registerActivities(myActivities)).
  • Client configuration pointing to the Temporal Service endpoint and namespace.
• Kubernetes manifests:
  • Deployment for the Worker pods (with environment variables/ConfigMaps for Temporal host, namespace, and TLS configuration).
  • Optionally, HorizontalPodAutoscaler or custom autoscaling based on queue depth or business metrics.

---

How should we think strategically about moving from local dev to Kubernetes with Temporal?

Short Answer: Treat the Temporal dev server as your proving ground for Durable Execution semantics, then use Kubernetes to scale Workers horizontally while delegating orchestration and state to the Temporal Service (self-hosted or Temporal Cloud).

Expanded Explanation:
The mistake many teams make is to treat Temporal like “just another workflow engine” and immediately jump into cluster diagrams. Don’t do that. Start by simplifying your application logic: replace brittle state machines, ad-hoc retry loops, and cron jobs with Temporal Workflows and Activities. Validate this on your laptop with temporal server start-dev. Crash everything. Pull the plug. Watch your Workflows resume exactly where they left off by replaying their histories.

Once you trust the programming model, Kubernetes becomes “just” a Worker pool. You use it to scale execution capacity, not to orchestrate state transitions. Temporal handles timers, retries, child Workflows, and signals; the Kubernetes scheduler just ensures you have enough Worker pods pulling tasks. That’s the strategic win: you move orchestration out of YAML, bash, and custom glue code, and into a single, observable, debuggable execution engine.

Why It Matters:

• Less operational toil: You stop writing and maintaining custom recovery scripts, reconciliation jobs, and glue DAGs; Temporal guarantees completion and lets Workers come and go.
• Faster iteration and safer releases: You can change Workflow code, replay histories, and debug failures via the Web UI before scaling out in Kubernetes, reducing the blast radius of changes.

---

Quick Recap

Start Temporal locally with temporal server start-dev, build your first Workflows and Activities against that dev server, and use the Web UI at http://127.0.0.1:8233 to see exactly what your code is doing. Once you’re confident in the model, containerize your Workers and deploy them to Kubernetes as simple, horizontally-scalable deployments that connect to a production Temporal Service or Temporal Cloud namespace. Temporal owns durability, replay, and orchestration; Kubernetes just runs your Worker pods. No lost progress, no orphaned processes, no manual recovery runs.

Next Step

Get Started