Extension URLs

Synapse extensions are self-contained, compiled code modules. They can be loaded from many different sources including the local file system, S3-compatible storage, and HTTP servers. For security purposes, it’s highly recommended that you only use extensions from trusted sources and pin them to specific versions using checksums.

A typical extension URL takes the following form:

The checksum parameter is optional but is highly recommended for security. It can be appended to any URL kind listed below — including plain file paths.

Supported URL formats
Built-in extensions (where supported)
  • system://sqldb

Local files
  • /path/to/extension.wasm

  • /path/to/extension.star?checksum=sha256:677cce2788330f16f27981130eaa50aa4189beab2121903bcea5b3c4c918dccc

HTTP
Git
  • wasm+git::https://github.com/org/repo//extension.wasm

  • wasm+git::ssh://git@github.com/org/repo//extension.wasm?ref=v1.0.0

Amazon S3
  • wasm+s3::https://s3.amazonaws.com/bucket-name/example.wasm

Google Cloud Storage
  • starlark+gcs::https://www.googleapis.com/storage/v1/bucket-name/example.star

Synapse selects the runtime from the URL path: .star for Starlark, .wasm for WebAssembly (WASM), and native otherwise. Getter URLs such as git::, s3:: and gcs:: require a native+, starlark+ or wasm+ runtime prefix because the artifact path is not available during runtime selection.

HTTP

Credentials are read from URL user information or ~/.netrc.

Amazon S3

Credentials are read from the standard AWS credential chain.

Google Cloud Storage

Credentials are read from Application Default Credentials.

Use the s3:: or gcs:: getter to authenticate an object-store request. A plain HTTPS URL is fetched without object-store authentication. Azure Blob Storage URLs are not supported.

Loading and refresh

Synapse fetches and compiles extensions during startup. Restart Synapse after changing an extension artifact, including a local file or a file mounted through a Kubernetes ConfigMap. Reloading the policy store does not reload extensions.