Temporal enables you to write and maintain less code and can help you and your teams adopt and improve a set of distributed systems best practices. Temporal 1.20 introduces several capabilities that extend these best practices to allow you to simplify Temporal development environments and gain more control over scheduling Workflows.
Simplify local development with Temporal CLI
Development environments for Temporal have historically been easy to run thanks to our automation, however, under the hood, they’re fairly complex to set up and maintain, as you are required to run multiple containers for Temporal, Elasticsearch, and Postgres. This complexity could even cause issues with reliability within this local environment.
A few months ago, the Datadog team contributed a project called Temporalite to the community, and with 1.20, we now package it as part of core Temporal. This open-source contribution greatly simplified setting up development environments and allowed developers to get up and running faster. With 1.20, we’ve added the capabilities as the Temporal CLI, which supports convenient installation with curl, Homebrew, or binary downloads and fully replaces the previous containerized setup.
brew install temporal curl -sSf https://temporal.download/cli.sh | shAll of our docs and guides are being updated right now, but we’re really excited to get this into your hands.
Also, in this release, we extend the Temporal CLI with Advanced Visibility, so that you can now query with more flexibility across all of your Workflow Executions to identify issues, recognize usage patterns, and optimize your code without any need for Docker. With this release, we also deprecate the ability to run Advanced Visibility directly on Cassandra without Elasticsearch.
Check out the Temporal CLI Github repo, and a big thanks to Datadog for contributing to this project! Note: we’ll continue to support Tctl for the next two releases.
The new way to schedule Workflows in Temporal
Many use Temporal to execute reliable and flexible cron jobs at scale. Until recently, the only way to run a Workflow on a set schedule was with a Temporal Cron Job. However, Temporal Cron Jobs could not be stopped or paused, or modified—only deleted. To gain these capabilities, some have relied on external schedulers, like Quartz, to resolve this, but it added implementation complexity and cost.
With 1.20, the new Scheduled Workflows capability is now GA and provides you with the tools necessary to:
- Gain visibility into Schedules and Workflow runs
- Create Schedules that are independent entities (separate from the Workflows they start)
- Have a Schedule specification of when the Workflow should be run that is structured and extensible
- Edit a Schedule’s specification
- Give Schedules a state of either Paused or Running
- Limit the number of runs
- Backfill runs that would have happened during a specific time range
- Overlapping runs are now possible
- Configure policies, for example, “buffer all runs”, “buffer one”, “cancel other”, etc
- Pause-on-failure
This enables you to systematically control scheduled Workflows without getting into an incorrect state and get visibility into scheduled Workflows, control and modify existing scheduled Workflows, and add policies and attributes to keep scheduled and long-running in the correct states.
Support for Schedules has been added to the CLI and the Web UI, and experimental APIs have been added to the Go SDK, the TypeScript SDK (see also a sample), and the Python SDK. Also, check out the Schedules docs.
Scheduled Workflows Demo
Demo: Introducing Scheduled Actions with Temporal v 1.20
A point of clarification in Ryland’s demo video: while Scheduled Actions is now the recommended solution for most scheduled scenarios, use cases which require high throughput may be a better fit on the original Temporal Cron functionality.
Additional features launched in 1.20:
- Archival feature reimplemented using a separate task queue
- Replication between clusters with different shard counts
- BatchOperation to support DeleteWorkflow
- OpenTelemetry upgraded to 0.34
- Security-related changes to the Default authorizer (which is confusingly not used by default)
- Internal frontend, which is a new deployment option that can simplify worker→frontend communication, mTLS, claim mappers, and authorizers
- Deprecation heads-up for older MySQL and Postgres versions