Release notes
v0.10.6 (2026-10-26)
- Update Cerbos PDP to 0.57.0
-
Update the in-process PDP to v0.57.0. See https://docs.cerbos.dev/cerbos/latest/releases/v0.57.0 for PDP release notes.
- Mitigations for insecure CA trust roots
-
Includes the latest CA trust roots. The eMudhra CA is no longer trusted.
v0.10.5 (2026-10-22)
- Clean up failed WASM extensions
-
Fixes an issue where WASM modules closed by the runtime were returned back to the active pool.
v0.10.3 (2026-10-01)
- In-process PDP updated to Cerbos 0.56.0
-
The in-process Cerbos PDP is now based on Cerbos 0.56.0. See the Cerbos 0.56.0 release notes for its changes.
v0.10.2 (2026-09-23)
- Option to trust remote trace spans
-
The new
server.trace.trustRemoteSpanssetting 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. SettrustRemoteSpanstotrueto 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.
v0.10.1 (2026-09-08)
- Fixed startup with no extensions configured
-
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.
v0.10.0 (2026-09-07)
- Self-documenting extensions
-
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.
- Metadata and about endpoints
-
The new
/_cerbos/metaendpoint returns the metadata of the running instance and its active extensions as structured data. The/_cerbos/aboutendpoint renders the same information as a human-readable HTML page. To disable both endpoints, setserver.disableMetatotrue.
v0.9.9 (2026-09-01)
- Health checks with Tailscale and container defaults
-
The
healthcheckcommand 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_CONFIGnow defaults to the built-in default configuration. Pass the location of a mounted configuration file throughSYNAPSE_CONFIG, so that the server and the container health check read the same file. See Health check command.
v0.9.8 (2026-08-26)
- Health check settings come from configuration
-
The
healthcheckcommand now reads the address and TLS settings from the Synapse configuration file, given with--conf.pathor theSYNAPSE_CONFIGenvironment variable. Override individual values with--conf.set, for example--conf.set=server.listenAddress=synapse.local:3594. With no configuration, the command checks127.0.0.1:3594. The--host-port,--ca-certand--no-tlsflags introduced in v0.9.7 have been removed in favour of this approach. - Cerbos module calls follow the request
-
Calls made from Starlark extensions through the
cerbosmodule, 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.
v0.9.7 (2026-08-24)
healthcheckcommand-
The new
healthcheckcommand checks whether a Synapse instance is serving, in the same way ascerbos healthcheckdoes for the Cerbos PDP. The container image uses it as its DockerHEALTHCHECK. The--insecureflag skips server certificate verification.
v0.9.6 (2026-08-18)
- Multiple JWTs in declarative mappings
-
Declarative mappings for the Envoy and route extensions can now pass more than one JWT to the PDP. Use
auxData.jwtsto define named tokens, each with its own CEL expression, instead of the singleauxData.jwt. The two settings are mutually exclusive. - Fixed changes to
oneoffields in extensions -
Reading an unset
oneoffield 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 sameoneofthat was set.
v0.9.5 (2026-08-14)
- Server information endpoint
-
Synapse now exposes the Cerbos
/api/server_infoREST endpoint, so clients and tools that query the PDP version over HTTP work against Synapse as well.
v0.9.4 (2026-08-14)
- In-process PDP updated to Cerbos 0.55.0
-
The in-process Cerbos PDP is now based on Cerbos 0.55.0. See the Cerbos 0.55.0 release notes for its changes.
v0.9.2 (2026-08-11)
- Helm chart example values fixed
-
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.
v0.9.0 (2026-07-29)
- In-process PDP update
-
The in-process Cerbos PDP is updated to a Cerbos development version that precedes the Cerbos 0.55.0 release.
v0.8.3 (2026-06-12)
- Tracebacks for failing Starlark scripts
-
When a Starlark extension fails, Synapse now logs the script’s traceback, showing the file, line and call chain that led to the error.
v0.8.2 (2026-06-10)
- Proxy settings ignored for in-process connections
-
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. - Default values of unset fields kept in Starlark
-
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.
v0.8.1 (2026-06-08)
- x86-64-v2 CPU requirement
-
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.
v0.8.0 (2026-06-03)
- Testing framework for extensions
-
Synapse now includes a testing framework for Starlark and WASM extensions. Tests are written in Starlark and run with the
testcommand, which starts a fresh Synapse instance for each test suite and runs the test cases against it.
v0.7.6 (2026-05-22)
- Lists and maps in requests are editable from Starlark
-
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.
v0.7.5 (2026-05-19)
- Host information in HTTP requests
-
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.
v0.7.4 (2026-05-15)
- Real time in WASM extensions
-
WASM extensions now read the actual current time. Previously, time functions in WASM extensions didn’t return the wall-clock time.
v0.7.1 (2026-05-13)
- WASM extension logs
-
Log output from WASM extensions now appears in the Synapse logs.
v0.7.0 (2026-05-01)
- Built-in Aperture extension
-
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.
v0.6.2 (2026-04-23)
- OAuth client credentials in Starlark
-
The new
oauthmodule 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 optionalpersist_keykeeps the authenticated client across requests, so a new token isn’t fetched each time.
v0.6.1 (2026-04-21)
- Fixed loading of some configuration files
-
Synapse now loads configuration files that it previously rejected, in particular when values from the file are combined with overrides set with
--conf.set.
v0.6.0 (2026-04-20)
- AuthZEN endpoints
-
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.
v0.5.1 (2026-04-17)
- Fixed data source lookups
-
Starlark extensions can now look up values from data sources without passing query parameters. Previously, such lookups failed.
v0.4.0 (2026-04-09)
- Cerbos Hub environment variables
-
The in-process PDP now picks up Cerbos Hub settings supplied as
CERBOS_HUB_*environment variables, such asCERBOS_HUB_CLIENT_IDandCERBOS_HUB_CLIENT_SECRET. See Connecting Synapse to Cerbos Hub.
v0.3.0 (2026-03-24)
- Fixed header handling in the Claude Code extension
-
The Claude Code route extension now reads request headers correctly.
v0.1.0 (2026-03-23)
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:
-
Proxy extensions that enrich Cerbos requests and responses.
-
Route extensions that add HTTP authorization endpoints, including one for securing Claude Code.
-
An Envoy external authorization endpoint.
-
Extensions written in Starlark or WASM, or defined declaratively with CEL.
-
Data sources, including SQL databases.
-
A Starlark REPL for developing extensions.
-
A container image, a Helm chart and Tailscale support.