The Stigg Sidecar is a tiny service that runs alongside your main application, acting as a proxy between the host and the Stigg API. The service provides low latency entitlement checks, handles caching, and subscribes to real-time entitlement and usage data updates.The benefits of deploying the Sidecar service:
Less CPU consumption and memory footprint for the host application when compared to embedding the SDK directly.
Language neutral API defined in Protocol Buffers accessible over gRPC.
Support for in-memory cache or external cache (like Redis) for entitlements and usage data.
Scaled together with the main application, or independently if deployed as a standalone service.
The sidecar service can be deployed together with the host application/service by utilizing the sidecar pattern - meaning each application has a sidecar container next to it which it can send requests to.
Alternatively it can be deployed as a standalone service which can be accessed remotely over an exposed port.The service can be scaled horizontally to support a higher volume of requests, but keep in mind that if in-memory cache is used, there will be a higher ratio of cache misses. In case of a cache miss, the service will fetch the data over the network directly from API, and update the cache to serve future requests.The sidecar is not intended to be exposed to the internet or to be accessed from a browser.
Sidecar running with in-memory cache
Sidecar service can be deployed in the same network namespace (or same K8 Pod), as the main application.
Once entitlement data is fetched from the Stigg API, it is persisted in the local or external cache.Local cache invalidation is handled by the Sidecar service. If using an external cache, an instance of the Persistent Cache Service must be deployed as well to handle cache updates, as illustrated below:
Since Sidecar SDK version 3.0.0, the TLS connection method has been deprecated in favor of non-TLS. Please ensure you are running a compatible Sidecar image version 2.494.0 or later. For backwards compatibility details, check the changelog. TLS self-signed certificates will expire on January 26, 2026, so upgrading the Sidecar image is strongly recommended.
When the Sidecar encounters startup errors, such as an invalid API key or network errors to the Stigg API, it continues to run and serves entitlements from the:
The Sidecar exposes a GET /metrics endpoint that returns service metrics in Prometheus format.This endpoint includes both system-level and Sidecar-specific metrics. These metrics are helpful for monitoring the health and performance of your Sidecar service.
In order for the cached data to survive service restarted, or shared across multiple instances of the Sidecar service, you can use Redis as the cache layer by providing the REDIS_* environment variables, replacing <tag> with the latest version in the ECR Public Gallery:
Global fallback strategy can be set by providing the Sidecar service with the ENTITLEMENTS_FALLBACK environment variable. It expects a value in a JSON object in a string format.For example, the following global fallback configuration JSON structure:
Can be formatted using JSON.stringify and then set as value of ENTITLEMENTS_FALLBACK when running the container, replacing <tag> with the latest version in the ECR Public Gallery:
During local development or testing, you might want to avoid making network requests to the Stigg API.
To do this, you can run the Sidecar service in offline mode by enabling the offline option. When enabled, API key validation will always succeed, regardless of the key provided, replacing <tag> with the latest version in the ECR Public Gallery:
In offline mode, the Sidecar respects the global fallback strategy, and entitlement evaluations are limited to the values defined as fallback entitlements. All other Sidecar service methods will effectively become no-ops. For example, replacing <tag> with the latest version in the ECR Public Gallery: