Release notes

The in-process Cerbos PDP is now based on Cerbos 0.56.0. See the Cerbos 0.56.0 release notes for its changes.

The new server.trace.trustRemoteSpans setting controls how Synapse treats trace context received from callers such as Envoy. By default, remote spans are not trusted: spans created by Synapse are linked to the incoming span instead of becoming its children. Set trustRemoteSpans to true to make Synapse spans children of the caller’s span. A request then appears as a single trace across the caller and Synapse. See Remote span context.

Synapse no longer fails when its configuration doesn’t define any extensions. It starts and serves the Cerbos API in the same way as a standalone Cerbos PDP.

Extensions can now describe themselves through a manifest that states their purpose and the attributes they add to or change in PDP requests. Synapse combines the manifests of all active extensions into a data dictionary of the attributes that the instance adds to requests.

The new /_cerbos/meta endpoint returns the metadata of the running instance and its active extensions as structured data. The /_cerbos/about endpoint renders the same information as a human-readable HTML page. To disable both endpoints, set server.disableMeta to true.

The healthcheck command now skips the check when Synapse listens on a tailnet. Container health checks no longer fail for instances that serve traffic only through Tailscale.

In the container image, SYNAPSE_CONFIG now defaults to the built-in default configuration. Pass the location of a mounted configuration file through SYNAPSE_CONFIG, so that the server and the container health check read the same file. See Health check command.

The healthcheck command now reads the address and TLS settings from the Synapse configuration file, given with --conf.path or the SYNAPSE_CONFIG environment variable. Override individual values with --conf.set, for example --conf.set=server.listenAddress=synapse.local:3594. With no configuration, the command checks 127.0.0.1:3594. The --host-port, --ca-cert and --no-tls flags introduced in v0.9.7 have been removed in favour of this approach.

Calls made from Starlark extensions through the cerbos module, such as PDP checks, cache operations and data source lookups, are now tied to the incoming request. They are cancelled when the request is cancelled.

The new healthcheck command checks whether a Synapse instance is serving, in the same way as cerbos healthcheck does for the Cerbos PDP. The container image uses it as its Docker HEALTHCHECK. The --insecure flag skips server certificate verification.

Declarative mappings for the Envoy and route extensions can now pass more than one JWT to the PDP. Use auxData.jwts to define named tokens, each with its own CEL expression, instead of the single auxData.jwt. The two settings are mutually exclusive.

Reading an unset oneof field of a request from a Starlark extension no longer changes the request. Previously, reading such a field could clear the value of the field in the same oneof that was set.

Synapse now exposes the Cerbos /api/server_info REST endpoint, so clients and tools that query the PDP version over HTTP work against Synapse as well.

The in-process Cerbos PDP is now based on Cerbos 0.55.0. See the Cerbos 0.55.0 release notes for its changes.

The example values files that ship with the Helm chart, for Cerbos Hub, audit logging, cert-manager, Git and volume storage and OTLP, have been corrected.

The in-process Cerbos PDP is updated to a Cerbos development version that precedes the Cerbos 0.55.0 release.

When a Starlark extension fails, Synapse now logs the script’s traceback, showing the file, line and call chain that led to the error.

Synapse no longer routes connections to the in-process PDP through the proxy set in HTTPS_PROXY. Instances running behind an outbound proxy now reach the in-process PDP directly.

When a Starlark extension reads a request field that isn’t set and then modifies the default value it gets back, the change is now saved to the request. Previously, such changes were lost.

The x86-64 builds of Synapse are now compiled for the x86-64-v2 microarchitecture level. They require a CPU that supports the x86-64-v2 instruction set extensions, such as SSE4.2 and POPCNT.

Synapse now includes a testing framework for Starlark and WASM extensions. Tests are written in Starlark and run with the test command, which starts a fresh Synapse instance for each test suite and runs the test cases against it.

Starlark extensions can now modify lists and maps in requests, such as appending to a list of actions or adding to a map of attributes. Previously, they were read-only.

The host of incoming HTTP requests is now always available to extensions. Previously, extensions could receive an empty host. Synapse also reports a clearer error when an extension returns a payload in an unexpected format.

WASM extensions now read the actual current time. Previously, time functions in WASM extensions didn’t return the wall-clock time.

Log output from WASM extensions now appears in the Synapse logs.

Guardrails for Aperture by Tailscale are now provided by a built-in extension, system://aperture, instead of a Starlark script. See Guardrails for Aperture by Tailscale for the updated configuration.

The new oauth module creates HTTP clients that obtain a token with the OAuth client credentials flow and attach it to every request. Extensions can use it to call APIs protected by OAuth, such as identity providers and directories. An optional persist_key keeps the authenticated client across requests, so a new token isn’t fetched each time.

Synapse now loads configuration files that it previously rejected, in particular when values from the file are combined with overrides set with --conf.set.

Synapse now serves the AuthZEN access evaluation API, for single and batch evaluations. Proxy extensions can modify AuthZEN requests and responses in the same way as Cerbos check and plan requests.

Starlark extensions can now look up values from data sources without passing query parameters. Previously, such lookups failed.

The in-process PDP now picks up Cerbos Hub settings supplied as CERBOS_HUB_* environment variables, such as CERBOS_HUB_CLIENT_ID and CERBOS_HUB_CLIENT_SECRET. See Connecting Synapse to Cerbos Hub.

The Claude Code route extension now reads request headers correctly.

First release under the Cerbos Synapse name. Synapse serves the Cerbos API over HTTP and gRPC and can run with an in-process PDP or in front of existing PDPs. This release includes: