Architecture

Delinea Credentials Cache is a stateless ASP.NET Core web service. Each instance keeps its own local cache of secrets, authenticates to Secret Server or the Delinea Platform on behalf of the calling application, and exposes a small REST API (see API Reference). This topic describes the components involved, how a request flows through them, and how the service behaves when you deploy more than one instance.

Components

  • Vault (source of truth) — Secret Server (Cloud or On-Premise) or Secret Server on the Delinea Platform. The cache never modifies secrets; it only reads them.

  • Delinea Credentials Cache — the web service that receives requests from applications, fetches secrets from the vault, and serves them from its local cache for the configured time-to-live (TTL, 10 minutes by default).

  • Client applications — for example the Delinea JDBC Proxy Driver in Tomcat or WebSphere, or a ServiceNow MID Server credential resolver. Clients call the cache instead of calling the vault directly.

  • Distributed Engine and Event Pipelines (optional) — when event-driven refresh is configured, an Event Pipeline in the vault runs a PowerShell script on a Distributed Engine, and that script tells the cache which secret changed.

Where the Service Runs

Delinea Credentials Cache is a web service that can be hosted on any Windows (IIS), Linux (Apache HTTP Server reverse proxy with systemd), or Docker host. It does not have to be installed on a Distributed Engine. The only placement requirements are that client applications can reach the cache over HTTP or HTTPS, that the cache can reach the vault, and, if you use event-driven refresh, that the Distributed Engines that run the Event Pipeline script can reach the cache. Event Pipelines themselves always execute on Distributed Engines.

You can deploy multiple Delinea Credentials Cache instances across different servers or Distributed Engines, for example one per region or per environment. Each instance operates independently and maintains its own local cache.

Architecture Overview

Request Flow

On-Demand Retrieval (TTL-Based)

  1. The application calls POST /api/token with its vault credentials and receives a Bearer token.

  2. The application calls GET /api/credential/{id} with the token.

  3. If the secret is in the cache and its TTL has not expired, the cache returns it immediately.

  4. Otherwise, the cache fetches the secret from the vault, stores it locally, and returns it. The secret stays cached for the configured TTL; the next request after expiry fetches the current value again.

The cache stores any secret that is requested through the API. It is not limited to MID Server credentials, and it supports multiple integrations at the same time.

Event-Driven Refresh

With event-driven refresh configured, the cache is updated as soon as a password changes rather than when the TTL expires. The high-level flow is:

  1. A secret password changes in Secret Server or the Delinea Platform.

  2. The Event Pipeline Policy evaluates the trigger and finds a match.

  3. A pipeline task is created and sent to the Distributed Engine of the selected Site.

  4. The Distributed Engine executes the PowerShell script.

  5. The script calls the Credentials Cache /api/secretchanged endpoint with the changed Secret ID.

  6. Credentials Cache fetches the updated secret from the vault.

  7. The local cache is refreshed with the new value.

How the Run Site Is Evaluated

When the Event Pipeline task runs, the vault only considers Distributed Engines that are registered to the Site selected in the task. The job is sent only to Distributed Engines within that Site. If the Site contains several Distributed Engines, one healthy engine picks up the job, runs the script, and the cache instance that the script targets fetches and refreshes the secret. To update several cache instances, configure the pipeline so that each instance is notified (for example, one Run Script task per cache URL, or a secret per instance).

Multiple Instances, Load Balancing, and Synchronization

Delinea Credentials Cache does not require load balancing or cache synchronization between instances. There is no central synchronization mechanism; each instance fetches secrets directly from the vault when a client requests them or when an Event Pipeline notifies it. When event-driven refresh is configured for all instances, every instance receives the update trigger and independently fetches and caches the updated secret.

Best practices:

  • Deploy at least two instances to avoid single-instance unavailability and to provide high availability.

  • Use Event Pipelines to trigger secret updates consistently across all instances.

  • For region-wise or environment-wise deployments, place an instance close to the applications that use it; each instance retrieves and caches secrets independently.

Consistency Across Regions

Consistency is achieved through a centralized source of truth (Secret Server or the Delinea Platform) combined with Event Pipeline notifications. When a secret changes, all deployed cache instances receive the update trigger and independently retrieve the latest value from the vault.

High Availability

If a Credentials Cache instance becomes unavailable, other instances continue to operate normally and there is no impact on secret availability. When the instance comes back online, it retrieves secrets during the next update trigger or on the next on-demand request.

For the deployment paths available, see Deployment Options.