Gateway Caching

Use this section to choose the right Gateway caching method for your environment.

Cache Types

Gateway caching has four practical patterns to choose from:

Type	Best for	Avoid when
Runtime Caching	Standard request acceleration and reduced repeated SaaS fetches	You need all reads to always bypass cache
Proactive Caching	Pre-warming and refresh jobs to reduce first-read latency	Your environment is rate-limit constrained
Cluster Cache (Standalone)	Shared Redis cache for multi-pod Gateway with low operational overhead	You require cache failover across Redis node or pod failures
Cluster Cache High Availability (HA)	Sentinel-based high-availability cache service for resilient shared cache	You prefer the simplest deployment footprint and can accept standalone Redis risk

Choosing a Caching Method

Use this starting decision flow:

Start with runtime caching for most environments.
Add proactive caching when you need faster first-read performance for frequently used secrets.
Add standalone cluster cache when running multiple Gateway pods that should share cache state.
Use Cluster Cache High Availability (HA) when shared cache availability across failures is a requirement.

For planning guidance and tradeoffs, see Gateway Best Practices: Caching strategy considerations.

For Kubernetes proactive cache sizing guidance, see Gateway Best Practices: Resource planning for Kubernetes proactive cache.

Configure in Gateway UI

To manage cache runtime settings from Gateway Configuration Manager:

Open https://<your-gateway-url>:8000/console.
Go to Gateways > Your Gateway > Manage Gateway > Caching Configuration.
Configure cache and proactive cache options.
Save changes.

For Kubernetes deployment keys (globalConfig.clusterCache, cacheHA, and persistence options), see Helm Values Reference.

ignore-cache Behavior

The ignore-cache flag is intended to bypass cache and fetch directly from SaaS.

akeyless get-secret-value --name /mysecret --ignore-cache true

In disconnected mode (when SaaS is unreachable), runtime still checks cache first even when ignore-cache=true. If the value is not cached, the request fails.

Updated about 1 month ago