Cloudflare Flagship Rust SDK: HTTP, local evaluation, or caching?

Check the runtime and token permissions first

Cloudflare announced its official Flagship Rust SDK on November 10, 2026. It connects async Rust services through OpenFeature, a common feature-flag interface that lets an application choose behavior from a flag value. The current Rust documentation requires Rust 1.88 or later and a Tokio runtime, and explicitly excludes the Cloudflare Workers binding.

The documented installation command is cargo add cloudflare-flagship. Configuration uses a Flagship app ID, a Cloudflare account ID, and an API token. Default HTTP evaluation requires Flagship Evaluate or Flagship App Evaluate permission. account_id is required with app_id and is always required for local evaluation.

The announcement and SDK documentation were checked on November 12, 2026; the documentation page is dated November 4. These sources do not provide a complete plan, pricing, regional, or account-eligibility matrix. SDK availability does not establish free access or eligibility for a particular account; check that account's Flagship service permissions.

HTTP evaluation: register the provider and handle Result

Set app_id, account_id, and auth_token with FlagshipClientOptions::builder(), then call build(). Create a FlagshipServerProvider and register it with OpenFeature. Create a client, supply an EvaluationContext with a targeting key, and call a method such as get_bool_value. The targeting key identifies the evaluation subject. The official example identifiers user-42 and new-checkout are demonstrations; replace them with your intended flag and authorized context.

The SDK supports OpenFeature server-side boolean, string, float, integer, and structured flag types. The Rust OpenFeature SDK does not pass a default value to providers: evaluation methods return Result. Handle errors and choose an appropriate application fallback. For example, unwrap_or(false) in the official example returns false on an error; it does not establish that the remote flag's actual value is false.

A disabled flag resolves to the value served by Flagship with the Disabled reason, which differs from a network error. Use get_*_details when you need the value, variant, reason, metadata, or error code. Recording only a boolean can discard the information needed to diagnose the result.

Local evaluation: download definitions and manage refreshes

With local_evaluation(true), the provider downloads the app's flag definitions and evaluates them in-process, without a network request for each evaluation. Downloading definitions requires Flagship Read or Flagship App Read permission. A token that can evaluate over HTTP does not necessarily have that permission. Local evaluations do not appear in Flagship analytics, so missing analytics records alone do not establish no usage.

Explicitly call initialize_provider() before registering a local provider, and shutdown_provider() when it is no longer needed. The Rust OpenFeature SDK does not call these methods for you. Initialization returns an error if the first definitions download fails; handle that outcome rather than assuming startup will succeed.

Definitions refresh in the background, with a default refresh_interval of 30 seconds. If a background refresh fails, the provider keeps serving the last downloaded definitions and reports STALE. Call last_refresh_error() to inspect the cause. A returned value in this state does not establish that the configuration is current or that the remote flag has stayed unchanged.

This local evaluation mode differs from the local flag store used by Wrangler development tools. That workflow involves explicit pulls and shared data paths, covered separately at https://puppyip.com/en/resources/cloudflare-flagship-local-defaults-dev-store-guide . Do not apply CLI store troubleshooting directly to the Rust provider's downloaded definitions.

Response caching: repeated requests with a defined freshness window

Response caching is off by default. Setting cache_ttl above zero lets the provider cache evaluations for repeated flag and context pairs, avoiding repeated remote round trips. cache_max_entries defaults to 1,000, with LRU eviction above that capacity. The documented 30-second TTL is an example setting, not a cache duration enabled by default.

An entry is keyed by flag key, flag type, and the full evaluation context, so different contexts do not share a cached value. Cache hits have the Cached reason. Disabled flags, errors, and type mismatches are never cached. A Flagship change becomes visible to subsequent remote fetching after the entry expires; do not promise immediate propagation while an entry is cached.

Local evaluation and response caching cannot be combined. Consider local evaluation when you want to avoid per-evaluation requests and can manage definition refreshes. Consider response caching for repeated queries with the same context when an explicit TTL is acceptable. Keep the default HTTP path when fresh remote results matter, while handling failure fallbacks and latency according to the application.

Network checks: context, per-attempt timeouts, and retries

Context containing only strings, finite numbers, booleans, or date-time values is sent as GET query parameters. Structured context uses POST with a JSON body. Context attributes are not secret storage: select only the attributes needed under your data policy and check their visibility in network logs. Unsupported values or context exceeding Flagship limits return INVALID_CONTEXT without an HTTP request, so inspect the input first.

timeout defaults to 5 seconds per attempt. retries defaults to one retry for network errors, timeouts, and HTTP 408, 425, 429, or 5xx responses. Retries are capped at 10; retry_delay defaults to 1 second and is capped at 30 seconds. A complete call with retries and delays does not have a total 5-second budget. Coordinate it with the application's overall wait budget. The documented disable_timeout() option is not a recommendation to remove timeouts everywhere.

auth_token adds Bearer authentication. An explicit Authorization value in static_headers overrides auth_token, and values from the async header_factory override both static headers and auth_token. When authentication fails, check the actual header source and its permissions, rather than only the token initially set in the options.

The default rustls feature uses Rustls for TLS. The documented alternative for the platform TLS library is cargo add cloudflare-flagship --no-default-features --features native-tls. Choose for the actual runtime environment. No dependencies were installed, accounts accessed, or real evaluations executed for this guide; these sources do not establish tested connectivity on a particular platform.

Validate each mode before expanding its use

Within an authorized test scope, confirm the runtime, app and account IDs, flag type, and minimum permissions. Use a known targeting key to check the value and reason, then check Result handling on failure. The application should determine its fallback value; do not mechanically apply the official false example to every business operation.

For local evaluation, check the initial download, background refresh, STALE diagnostics, and shutdown separately. For caching, check the hit reason, context separation, and updates after the TTL. A successful return, fresh definitions, and a log or analytics record are different observations; one does not replace the others.

Retain the actual SDK version and documentation date, then adjust timeouts, retries, or refresh intervals for the application. A published SDK, sample code, or documented eligibility is not evidence of deployment, account activation, or results. Proxy and network settings cannot replace Cloudflare's service permissions, pricing, or rules.