SDK × filter matrix
This page maps each catalog filter to where it is evaluated: the Definitions worker, the SDK process (server-local), or neither (unknown filters fail closed). Filter parameter shapes live in the Feature filters reference.
Cells reflect built-in evaluators in current FeatureManagement packages (and the separate PHP repo where noted). — / Unknown means no built-in support is established. Package versions and custom evaluators can extend this matrix.
Evaluation modes
| Mode | When | Endpoint / package |
|---|---|---|
| Worker | Client / browser / mobile / Electron SDKs using pre-evaluated flags | evaluated-signed on definitions.toggly.io |
| Local | Server SDKs that download signed definitions and evaluate in-process | definitions-signed + language eval engine (e.g. Go toggly/eval, @ops-ai/toggly-eval, .NET FeatureManagement) |
| Fail-closed | Missing required context, missing entity for ContextProperty, or an unknown / unregistered filter name | Feature stays off (or .NET throws by default for missing registered filters) |
See support floors for runtime and framework requirements.
Client-side note: User and HTTP-segment filters run on the worker. ContextProperty may return an EntityGate; the client evaluates that gate locally and fails closed without entity context. See Evaluated-signed and Entity & page context.
The JavaScript browser SDK does not expose per-call browser user-agent/country overrides. Its check arguments after the key are entity context and kind. Worker support for a filter is not proof of a browser API to override that filter's inputs.
NestJS: The NestJS HTTP adapter uses the Node / toggly-eval column. Its request context factory supplies identity, groups, claims and HTTP fields; per-call entity overrides support ContextProperty.
Hybrid note: Next.js / Nuxt / Remix / SvelteKit server packages that use @ops-ai/toggly-eval follow the Node / toggly-eval column. Prefer ambient EvalContext (bind once per request) so segment + UserClaims filters run without per-call props; per-call options remain overrides. Their browser bundles follow Client SDKs (worker).
SvelteKit: createTogglyHandle captures request headers and binds identity/groups/claims once per request. Server evaluation uses Node core; the explicitly allowlisted hydration snapshot and browser refreshes use frontend worker evaluation.
Astro / Gatsby request context: Server rails evaluate with @ops-ai/toggly-eval and forward init-time groups / claims into EvalContext. They do not wire per-request EvalContext.request (UA / Accept-Language / country), so HTTP segment filters stay fail-closed unless you evaluate elsewhere (e.g. Node adapters) or extend the integration.
Blazor: trusted server sessions use the core .NET filters and per-evaluation targeting context. They do not register the .Web HTTP-context segment or UserClaims filters for circuits. Browser sessions use the evaluation endpoint and local entity gates. See Blazor filter boundaries.
Legend
| Symbol | Meaning |
|---|---|
| Local | Built-in in-process evaluator |
| Worker | Evaluated by Definitions worker |
| Web | Built-in only with the HTTP / web integration package |
| — | Not a built-in; unknown name → fail-closed |
| Gate | Worker may return EntityGate; client evaluates locally (fail-closed without entity) |
Shared catalog filters
| Filter | Definitions worker | .NET | Go | Node (toggly-eval) | Java | Python | Rust | Ruby | PHP core | Elixir | Client SDKs |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Always On | Worker | Local | Local | Local | Local | Local | Local | Local | Local | Local | Worker |
| Always Off | Worker | Local* | Local | Local | Local | Local | Local | Local | Local | Local | Worker |
| Percentage | Worker | Local | Local | Local | Local | Local | Local | Local | Local | Local | Worker |
| Targeting | Worker | Local | Local | Local | Local | Local | Local | Local | Local | Local | Worker |
| Time Window | Worker | Local | Local | Local | Local | Local | Local | Local | Local | Local | Worker |
| Browser Family | Worker | Web | Local | Local | Local | Local | Local | Local | Local | Local | Worker |
| Browser Language | Worker | Web | Local | Local | Local | Local | Local | Local | Local | Local | Worker |
| Country | Worker | Web | Local | Local | Local | Local | Local | Local | Local | Local | Worker |
| Device Type | Worker | Web | Local | Local | Local | Local | Local | Local | Local | Local | Worker |
Operating System (OS) | Worker | Web | Local | Local | Local | Local | Local | Local | Local | Local | Worker |
| User Claims | Worker | Web | Local | Local | Local | Local | Local | Local | Local | Local | Worker |
| Context Property | Gate | Local | Local | Local | Local | Local | Local | Local | — | Local | Gate |
* .NET registers Microsoft FeatureManagement stock filters plus Toggly percentage/targeting/time-window/context-property; Always On/Off come from the FeatureManagement pipeline.
PHP note: Local segment + UserClaims evaluation lives in PHP core FeatureManager (with claims / request on the context array, or HttpRequestMapper for headers). Laravel classes under Toggly\Laravel\Filters\ are legacy and are not the evaluation path.
Aliases
Definitions serve short names (Percentage, Targeting, TimeWindow) for every stack. Document and configure those names — not Microsoft.* — in non-.NET SDKs. Elixir, Go, Node (toggly-eval), Java, Python, Rust, Ruby, and PHP core also accept OperatingSystem and CountryFamily aliases for OS / Country. Prefer the names in the Feature filters reference.
Fail-closed behavior (unknown filters)
| Runtime | Unknown / missing evaluator |
|---|---|
| Definitions worker | Filter does not enable the feature |
Elixir / Go / Node (toggly-eval) | Treated as non-passing (All → off; Any → ignored for pass) |
| Java / Python / Rust / Ruby / PHP core | Returns false for that filter |
| .NET | Throws by default when a configured filter type is not registered (fail closed); opt-in ignore is available and unsafe |
Missing identity for Percentage / Targeting mid-range rollouts, missing request / claims fields for segment / UserClaims filters, and missing entity for Context Property, also fail closed. See the filter reference and server-side reliability.
SDK-specific filters (outside shared catalog)
| Filter | Where | Notes |
|---|---|---|
ContextualTargeting | Rust, Ruby | Trait/context targeting in those SDKs; not in the shared dashboard catalog docs |
Passing EvalContext (JS local-eval)
The Node (toggly-eval) column means the evaluator understands the filter. You still must supply context — prefer ambient (configure once per request), with per-call options as overrides:
| Package | Ambient (recommended) | Overrides |
|---|---|---|
| Next.js server | withEvalContext / runWithEvalContext (Node runtime / root helper — not Edge middleware; ALS uses node:async_hooks). Then isServerFeatureOn('X') / <Feature featureKey> without props. | FeatureCheckOptions on helpers / <Feature> props |
| Nuxt server | configureEventEvalContext or defineTogglyContextMiddleware (getIdentity / getGroups / getClaims / getContext). Then useEventToggly / isEventFeatureOn. | isServerFeatureOn(key, options) or client.isFeatureOn(…, overrides) |
| Remix server | createTogglyLoader / action helpers with getIdentity / getGroups / getClaims / getContext; prefer run. UserClaims via claims only (not traits). | IdentityContext on isEnabled / gates |
| Express / Hono / Fastify / Koa | Middleware getIdentity / getGroups / getClaims (or getContext); fromHttpRequest fills request. Then isFeatureOn('X'). | Core client.isFeatureOn(key, context); request helpers accept only the key |
| Astro / Gatsby | Init-time groups / claims only; no per-request request wiring today. | — |
| Elixir | Toggly.Context.from_headers/2 and Toggly.Phoenix.Plug map headers; claims/identity remain explicit per request. LiveView uses socket context or a signed session. | — |
| Go | Populate toggly.Context (Claims, Request, …) yourself — togglyhttp does not map headers automatically. | — |
| Java / Python / Rust / Ruby / PHP core | Set claims + request on evaluation context (or language HttpRequestMapper / from_http_headers / fromHttpHeaders). Framework middleware may not auto-map headers — wire them when you need segment filters. | — |
| .NET Web | AddTogglyWeb registers HTTP segment + UserClaims filters against HttpContext (already ambient). | Console / non-Web hosts need contextual evaluation |
init* / plugin defaults for identity / groups / claims are process-wide on shared clients. Prefer ambient request-scoped providers (or per-call overrides) on concurrent servers.
How to use this matrix
- Prefer filters marked Local or Worker for your SDK column.
- For HTTP segment filters and UserClaims on Java / Python / Rust / Ruby / PHP core, populate
claimsandrequest(or map headers with the SDK’sHttpRequestMapper/ equivalent). Missing context fails closed — same contract as Go / Node. Astro / Gatsby still lack per-requestrequestwiring; see the request-context note above. - Match runtime floors on the Support floors hub.