The Temporal Rust SDK sits on a Core SDK that four other language SDKs already use

Two published crates and a shared Core underneath

The repository is described as Temporal Rust & Core SDKs, and it publishes two things a Rust user would depend on. There is temporalio-sdk on crates.io, the Temporal Rust SDK, and temporalio-client, the Temporal Rust Client. Both have docs.rs pages, and the README points at a separate README in each crate directory for usage and examples.

Underneath them is the part that makes the project interesting. The Temporal Core SDK is a Core SDK that can be used as a base for other Temporal SDKs, and it is currently used as the base of the TypeScript SDK, the Python SDK, the .NET SDK and the Ruby SDK.

That is an unusual shape for a language SDK. Rather than four independent implementations of workflow replay, retry semantics and activity handling, there is one Core, written in Rust, and the language layers sit on top of it. The Rust SDK is therefore both a client in its own right and the language that happens to sit closest to the Core.

The crate list in the README makes the structure explicit. There is temporalio-client for interacting with the Temporal gRPC service, temporalio-common for common code and protobuf definitions, temporalio-sdk-core as the Core implementation, temporalio-sdk-core-c-bridge providing C bindings for Core, temporalio-macros for the procedural macros used by Core and the SDK, and temporalio-sdk as the Rust SDK built on top of Core.

The licence is MIT, recorded in the workspace Cargo.toml with a licence-file pointing at LICENSE.txt, and the last push to the repository was on 2026-10-20. The recent releases are v1.1.0 for the SDK on 2026-10-06, core-v0.10.0 for Core on the same day, and v1.0.0 for the SDK on 2026-09-04, so both halves are being released together and both are young.

The workspace layout, and what each crate is for

The root Cargo.toml lists the workspace members and they line up with the README's crate descriptions, with a few extras.

[workspace]
members = [
    "crates/sdk-core",
    "crates/client",
    "crates/common",
    "crates/common-wasm",
    "crates/protos",
    "crates/macros",
    "crates/sdk",
    "crates/workflow",
    "crates/sdk-core-c-bridge",
    "crates/changelog-release-notes",
]
resolver = "3"

Two members are not in the README's list. crates/common-wasm is the WebAssembly counterpart of the common crate, and crates/workflow holds the workflow definitions that the SDK builds on, separated from the Core implementation itself.

That separation is the point of the whole design. The Core knows about workflow execution and state, and the workflow crate knows about the things a workflow author writes. The client crate is the gRPC surface. The Core talks to the client, so the same Core runs whether the language on top is Rust, TypeScript or Ruby.

The workspace also sets up a shared dependency set, which is where the RPC stack is visible. tonic at 0.14.6 with tonic-prost and tonic-prost-build for the gRPC layer, prost at 0.14 for the protobuf runtime, prost-types at 0.7 under the prost-wkt-types package name, and pbjson at 0.9 for JSON encoding of protobuf messages. opentelemetry at 0.32 is there with the metrics feature, and thiserror at 2 for the error types.

Two workspace lints are configured, unreachable_pub as a rust lint warning and dbg_macro as a clippy warning. The release profile inherits release with lto enabled, which is the standard choice for a library that ends up inside someone else's binary.

The repository also holds an ARCHITECTURE.md document with high-level information about how Core works and how language layers interact with it, and a blog post explaining the reasoning behind the Core.

Building and testing: cargo build, cargo test, and a feature flag

Building and testing is done with cargo, and the README gives two commands: `cargo build` to compile, and `cargo test --features experimental` to run the test suite.

The experimental feature is worth noticing. The load tests are run with cargo test --features experimental --test heavy_tests, so the experimental flag gates the heavier suite rather than the whole test run.

Then there is the integration test harness, which is the most interesting piece of tooling in the README. Run integ tests with cargo integ-test, and by default it will start an ephemeral server. That single sentence is a big deal for a workflow engine, because it means a developer can run the integration suite without provisioning a Temporal server, without a namespace, and without cleaning anything up afterwards.

The alternative is an already-running server, which you select with -s external.

There is a third mode for target-compatible tests, and it is the mode with the most moving parts.

TEMPORAL_ADDRESS=namespace.account.tmprl.cloud:7233 \
TEMPORAL_NAMESPACE=namespace.account \
TEMPORAL_API_KEY=... \
cargo integ-test -s envconfig -- \
  integ_tests::workflow_tests::timers::timer_workflow_workflow_driver --exact

The envconfig mode reads a client configuration, and the README links the client README for what that configuration is. TEMPORAL_CONFIG_FILE and TEMPORAL_PROFILE can select a TOML profile instead, and in this mode the harness does not start, configure, or clean up the target server or namespace.

So there are three tiers: an ephemeral server for the default run, an external server you manage, and a configured target such as Temporal Cloud that the harness only drives.

Cloud compatibility is declared per test, not per crate

The mechanism for running against Temporal Cloud is more considered than most projects manage, and it is worth understanding because it tells you how the project thinks about a hosted service.

Tests are Cloud-eligible by default. An incompatible test must select a CloudTestExclusionReason at the test function.

#[temporalio_macros::cloud_test_exclusion(
    crate::CloudTestExclusionReason::DoesNotUseServer
)]
#[tokio::test]
async fn example() {
    // ...
}

The supported categories are DoesNotUseServer, RequiresLocalServer, RequiresOssOnlyApis, RequiresCloudProvisioning, and NeedsCloudAdaptation. An optional second string should only be used when it adds information beyond the category.

The design is that the default is the hosted service, and opting out is a deliberate act with a reason attached. That is the opposite of the usual arrangement, where a test assumes a local server and the cloud run is a filtered subset.

The CLI supports the same idea in both directions. Pass --cloud to skip integration tests that do not exercise a server, require a local server or unavailable Cloud provisioning, or are not yet compatible with Temporal Cloud, and cloud filtering is independent of server selection.

cargo integ-test -s envconfig --cloud
cargo integ-test -s external --cloud -- --ignored --list

The second command lists the excluded cases without connecting to a server, which is how you find out what will be skipped before you run anything. In Cloud mode exclusions become native ignored tests, so --ignored --list lists the skipped cases.

That is a small but real piece of engineering discipline: the reason a test cannot run against Temporal Cloud is recorded in the test source rather than in a separate spreadsheet.

Protoc, tracing and the subtree that keeps the API in sync

Two developer-facing details in the README are worth flagging because they describe real friction.

First, you need the protoc protobuf compiler installed to build Core. That is a native toolchain prerequisite before you can even compile, on top of the Rust toolchain itself, and the repository pins the Rust version with a rust-toolchain.toml and configures tasks through mise.toml.

Second, the protobuf definitions are pulled in from upstream as a git subtree rather than a submodule. The path crates/protos/protos/api_upstream is a subtree, and to update it the README gives the exact command, using git pull with --squash and --rebase=false and the subtree strategy pointed at the temporalio/api repository.

The README then adds a line that is worth reading twice: do not question why this git command is the way it is, it is not our place to interpret git's ways. It is a joke, but it is also an accurate description of the situation, because a subtree update with a squashed history and a subtree strategy flag is not a command anyone invents themselves.

The same approach is used for the api-cloud subtree, and the Java test server protos are pulled from the sdk-java repository with git read-tree, because only a subdirectory of that repository is needed.

The tracing setup is the third detail. The crate uses tracing for debugging, and to enable it globally for tests you insert one line at the start of the test.

crate::telemetry::telemetry_init_fallback();

By default tracing data is output to stdout in a reasonably pretty manner, and the passed in options can be customised to export to an OTel collector. The repository ships etc/integ-with-otel.sh for running the integration tests with collection on, and it expects the collector to be running via docker-compose using the files in etc/docker.

Where the Temporal Rust SDK is the wrong choice

Three cases, and the first is a constraint of the Core rather than of Rust.

The Core is a native Rust library, and the SDK sits on it. That means the target has to be a platform the Core builds for. The repository's own integration notes mention macOS specifically, with a warning about Too many open files errors when running the integration tests on MacOS, and the fix being to raise ulimit -n to 65535 for the current shell or add it to the shell profile. A build that fails with an obscure file descriptor error on a development machine is a support burden that arrives on day one.

The second is the maturity of the two halves. The Rust SDK is at v1.1.0 and the Core is at core-v0.10.0. A 0.x Core means the API underneath the SDK is still moving, and the README's own structure suggests an active development phase: the experimental feature flag, the cloud exclusion categories, the subtree update procedure.

The third is documentation. The root README does not contain usage or examples. It points at crates/sdk/README.md and crates/client/README.md for that, and at ARCHITECTURE.md for the design. That is a reasonable layout for a monorepo, but it means a new user has to know which of several READMEs to read before writing a line, and the root document is about building, testing and contributing rather than about using the SDK.

There is also a licensing point worth checking rather than assuming. The Core is MIT, and the SDK is MIT, which is unusually permissive for the foundation layer of a hosted workflow engine. Anyone building on it should still read LICENSE.txt, and should be aware that the terms of the hosted service itself are a separate matter from the terms of the client library.

Maintenance, the changelog, and what the release cadence says

The repository is not archived and the last push was on 2026-10-20. The recent release tags show the two halves moving in step: the SDK at v1.1.0 and Core at core-v0.10.0 both on 2026-10-06, with the SDK's v1.0.0 on 2026-09-04.

A month between v1.0.0 and v1.1.0 for the SDK, with a Core release on the same day, is a fast cadence for a library that other SDKs depend on.

The repository has a CHANGELOG.md and, interestingly, a dedicated crate for it. The workspace members include crates/changelog-release-notes, which suggests the changelog is assembled by a build step rather than written by hand, and the root also has a CONTRIBUTING.md and an AGENTS.md.

Documentation can be generated from the workspace with cargo doc --workspace --all-features, and the output will be placed in the target/doc directory. That is the docs.rs pipeline in miniature, and it means the API reference and the source cannot drift apart.

Two smaller quality signals in the tree. There is a rustfmt.toml and a .clippy.toml, and the README notes that clippy is used for linting with a couple of aliases, cargo lint and cargo test-lint, that make sure various targets are hit. Formatting is cargo fmt --all. And there is a DOC_HIDDEN_IDENTIFIERS.md file, which is the kind of file a project keeps when it cares about the public documentation surface.

The cgroup test script, docker-cgroup-tests.sh, and the etc/ directory point at a further concern: the project tests behaviour under container resource limits, which for a workflow engine that runs arbitrary user code is not an optional concern.

Editorial conclusion

Adopt the Temporal Rust SDK if you want Temporal workflows in Rust and you are prepared to depend on a Core SDK that is still moving, with the Rust client at v1.1.0 and Core at core-v0.10.0 as of 2026-10-06. Do not adopt it if you need to run workflows on a runtime the Core does not support, since the Core is a native library and the SDK sits on top of it. Verify first that the feature set you need exists in the Rust client rather than only in the Core, because the README points usage and examples to a separate crates/sdk/README.md rather than documenting them here.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. temporalio/sdk-rust on GitHub