Skip to main content
Version: Config V2

ConfigCat Proxy

The ConfigCat Proxy allows you to host a feature flag evaluation service in your own infrastructure. It's a small Go application that communicates with ConfigCat's CDN network and caches/proxies config JSON files for your frontend and backend applications. The config JSON contains all the data that is needed for ConfigCat SDKs to evaluate feature flags.

The Proxy provides the following:

  • Performance: The Proxy can be deployed close to your applications and can serve the downloaded config JSON files from memory. ConfigCat SDKs then can operate on the proxied config JSON. This can reduce the duration of feature flag evaluation for stateless or short lived applications.
  • Reliability: The Proxy can store the downloaded config JSON files in an external cache. It can fall back to operating on the cached config JSON if the ConfigCat CDN network becomes inaccessible.
  • Security: The Proxy can act as a server side flag evaluation component. Using it like that can prevent the exposure of config JSON files to frontend and mobile applications.
  • Scalability: Horizontal scaling allows you to align with the load coming from your applications accordingly.
  • Streaming: The Proxy provides real-time feature flag change notifications via Server-Sent Events (SSE) and gRPC.

Architecture​

The following diagram shows the high level architecture of the Proxy.

High level Proxy architecture

How It Works​

The Proxy wraps one or more SDK instances for handling feature flag evaluation requests. It also serves the related config JSON files that can be consumed by other ConfigCat SDKs running in your applications.

Within the Proxy, the underlying SDK instances can run in the following modes:

  • Online: In this mode, the underlying SDK has an active connection to the ConfigCat CDN network through the internet.
  • Offline: In this mode, the underlying SDK doesn't have an active connection to ConfigCat. Instead, it uses the configured cache or a file as a source of its config JSON.

With the combination of the above modes, you can construct a cluster of proxies where only one node is responsible for the communication with ConfigCat, and all the other nodes are working from a central cache.

Load balanced Proxy architecture

Communication​

There are three ways how the Proxy is informed about the availability of new feature flag evaluation data:

  • Polling: The ConfigCat SDKs within the Proxy are regularly polling the ConfigCat CDN for new config JSON versions.
  • Webhook: The Proxy has webhook endpoints (for each underlying SDK) which can be set on the ConfigCat Dashboard to be invoked when someone saves & publishes new feature flag changes.
  • Cache polling / file watching: In offline mode, the Proxy can regularly poll a cache or watch a file for new config JSON versions.

These are the ports used by the Proxy by default:

Installation​

You can install the ConfigCat Proxy from the following sources:

Docker

The docker image is available on DockerHub. You can run the image either as a standalone docker container or via docker-compose.

Pull the docker image:

docker pull configcat/proxy

Run the ConfigCat Proxy:

docker run -d --name configcat-proxy \ 
  -p 8050:8050 -p 8051:8051 -p 50051:50051 \
  -e CONFIGCAT_SDKS='{"<sdk-identifier>":"<your-sdk-key>"}' \
  configcat/proxy
Standalone executable

You can download the executables directly from GitHub Releases for your desired platform.

You can then check the status endpoint of the Proxy to ensure it's working correctly: http://localhost:8051/status

Usage Scenarios​

This section describes the possible ways of how you can use the Proxy from your application. You can decide where you want the actual feature flag evaluation to happen.

  • Local evaluation: Feature flags are evaluated in your application by the ConfigCat SDK running in your application. The Proxy only provides the data required for the evaluation process.
  • Remote evaluation: Feature flags are evaluated within the Proxy, your application only gets the result of the evaluation process.

1. Local evaluation using a ConfigCat SDK connected to the Proxy​

The Proxy has the ability to forward all information required for feature flag evaluation to ConfigCat SDKs via its CDN proxy endpoint. This means that you can set up your ConfigCat SDK instances to use the Proxy as their data source.

To do this, you have to set the SDK's baseUrl option to the Proxy's host.

example.js (Initializing the ConfigCat JS SDK to use the Proxy with SDK Key)
import * as configcat from "@configcat/sdk";

const configCatClient = configcat.getClient(
  "#YOUR-SDK-KEY#", 
  configcat.PollingMode.AutoPoll,
  { baseUrl: "http://localhost:8050" } // Proxy URL
);

Additionally, as the Proxy maps unique identifiers to each configured SDK key it works with, you can use that identifier prefixed with configcat-proxy/ as the SDK key at the ConfigCat SDK's initialization.

example.js (Initializing the ConfigCat JS SDK to use the Proxy with SDK identifier)
import * as configcat from "@configcat/sdk";

var configCatClient = configcat.getClient(
  "configcat-proxy/#SDK-IDENTIFIER#", // SDK identifier prefixed with 'configcat-proxy/'
  configcat.PollingMode.AutoPoll,
  { baseUrl: "http://localhost:8050" } // Proxy URL
);

2. Remote evaluation with the Proxy's API endpoints​

You can leverage the Proxy's server side feature flag evaluation feature by sending simple HTTP requests to the Proxy's API endpoints.

example.js (Evaluating a feature flag with API)
const url = "http://localhost:8050/api/#SDK-IDENTIFIER#/eval"; // Proxy API URL with SDK identifier

const data = {
  key: "isMyAwesomeFeatureEnabled", // Feature flag key
  user: { // User Object for evaluation
    Identifier: "#UNIQUE-USER-IDENTIFIER#"
  }
};

const requestOptions = {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
  },
  body: JSON.stringify(data),
};

try {
  const response = await fetch(url, requestOptions);
  const responseData = await response.json();
  console.log(responseData); // {"value":<evaluated-value>,"variationId":"<variation-id>"}
} catch (error) {
  console.error('Error:', error)
}

You can find the available API endpoints with their HTTP request/response schemas here.

3. Remote evaluation with OpenFeature Remote Evaluation Protocol (OFREP)​

info

OFREP compatibility is only available from Proxy version v2.0.0.

The Proxy conforms to the OpenFeature Remote Evaluation Protocol, which means it can be used with OFREP compatible OpenFeature providers.

example.js (Initializing the OFREP JS Web provider to use the Proxy)
import { OpenFeature } from "@openfeature/web-sdk";
import { OFREPWebProvider } from '@openfeature/ofrep-web-provider';

OpenFeature.setProvider(
  new OFREPWebProvider({
    baseUrl: 'http://localhost:8050', // Proxy URL
    headers: [
      ['X-ConfigCat-SdkId', '#SDK-IDENTIFIER#'],
    ],
  }),
);

You can find the available OFREP endpoints with their HTTP request/response schemas here.

4. Remote evaluation and streaming with SSE​

The Proxy has the ability to evaluate feature flags and send notifications about subsequent evaluated flag value changes through Server-Sent Events connections.

example.js (Evaluating a feature flag and listening to changes with SSE)
const rawData = {
  key: "isMyAwesomeFeatureEnabled", // Feature flag key
  user: { // User Object for evaluation
    Identifier: "#UNIQUE-USER-IDENTIFIER#"
  }
}

const data = btoa(JSON.stringify(rawData))
const url = "http://localhost:8050/sse/#SDK-IDENTIFIER#/eval"; // Proxy SSE URL with SDK identifier

const evtSource = new EventSource(url + "/" + data);
evtSource.onmessage = (event) => {
  console.log(event.data); // {"value":<evaluated-value>,"variationId":"<variation-id>"}
};

For more information and usage examples, see the related SSE endpoints documentation.

5. Remote evaluation and streaming with gRPC​

The Proxy supports both unary feature flag evaluation RPCs and server streaming of evaluated flag value changes. For more information and usage examples, see the gRPC section of this documentation.

Configuration Options​

You can specify options for the Proxy either via a YAML file or with environment variables. When an option is defined in both places, the environment variable's value takes precedence.

By default, the Proxy reads the options YAML from the following default locations:

  • Windows: %PROGRAMDATA%\configcat\proxy\options.yml, usually C:\ProgramData\configcat\proxy\options.yml
  • macOS: /Library/Application Support/configcat/proxy/options.yml
  • Linux: /etc/configcat/proxy/options.yml

When the default location is not suitable, you can specify a custom location for your options YAML file via the -c argument.

Docker

When running the Proxy in docker, you can mount the options YAML file as a volume.

docker run -d --name configcat-proxy \ 
  -p 8050:8050 -p 8051:8051 -p 50051:50051 \
  -v <path-to-file>/options.yml:/etc/configcat/proxy/options.yml

(Optional) With the -c argument to specify a custom path for your options YAML file:

docker run -d --name configcat-proxy \ 
  -p 8050:8050 -p 8051:8051 -p 50051:50051 \
  -v <path-to-file>/options.yml:/cnf/options.yml \
  configcat/proxy -c /cnf/options.yml
Standalone executable

Run the Proxy as a standalone executable with the options YAML file in its default location:

./configcat-proxy

(Optional) With the -c argument to specify a custom path for your options YAML file:

./configcat-proxy -c /path-to-file/options.yml

The following sections will go through each available option in detail.

How does the Proxy learn about feature flags?​

In order to make the Proxy work properly, it must be set up with one or more SDK keys. It creates one SDK instance per SDK key internally and uses those for feature flag evaluation.

SDK Identifier​

Within the Proxy, SDK keys are mapped to unique SDK identifiers.

The SDK key identifies a config/environment pair and is used to configure an SDK instance to fetch the config JSON of that config/environment pair. The SDK identifier identifies an SDK instance running within the Proxy and configured to use the associated SDK key. That is, the SDK identifier is effectively an alias for the associated SDK key and is used in endpoint routes to avoid exposing the SDK Key.

There are two ways to let the Proxy know which SDK Keys it should use:

1. Automatic configuration with Proxy profiles​

info

Beta Feature: Automatic configuration with Proxy profiles is in public beta. We're now collecting feedback from real-world usage to fine-tune the experience. Share your feedback here.

info

The automatic configuration with Proxy profiles feature is only available from Proxy version v2.0.0.

The Proxy has the ability to use Proxy profiles to determine which SDK keys to download and distribute. It periodically checks for profile changes, allowing it to pick up the changes on the fly, without needing a restart.

You can set up Proxy profiles under the Manage organization -> Proxy Profiles menu on the ConfigCat Dashboard.

Proxy Profiles menu

To connect a Proxy instance to a Proxy profile, follow these steps:

  • Create a new Proxy profile​

    Click on the + ADD PROFILE button.

    Add Profile

    Give the profile a meaningful name and description, then click CREATE.

    Create Profile

  • Configure your Proxy instance​

    Grab the Key and Secret from the profile creation dialog and put them into the Proxy's configuration.

    Configure Proxy with key and secret
    options.yml
    profile:
      key: <key>
      secret: <secret>

  • Select which SDK Keys your Proxy should use​

    Click on the edit icon in the SDK Keys column.

    Click on Select SDK Keys

    Select the config/environment pairs whose SDK key you want to make available for your Proxy instance.

    Select SDK Keys
    info

    You can click config names in the first column to toggle all SDK keys in a row, or environment names in the column headers to toggle all SDK keys in a column.


  • Locate SDK identifiers for the selected SDK Keys​

    You can find the SDK identifiers generated for the selected config/environment pairs on the ConfigCat Dashboard right where you find their SDK Key.

    Click on view SDK identifiers for ConfigCat Proxy

    In the dialog that appears, you can find the SDK identifiers for the current config/environment pair, listed for each available Proxy profile.

    Click on view SDK identifiers for ConfigCat Proxy

  • (Optional) Set up how your Proxy should learn about feature flag changes​

    There are two ways a Proxy can detect feature flag changes. Each config/environment pair identified by each SDK key is automatically monitored for changes by periodic polling of the corresponding config JSON file at a configured frequency. Besides polling, the Proxy can receive change notifications over HTTP, via its webhook endpoint.

    • Config JSON poll interval​

      You have the option to control how frequently the Proxy should poll for config JSON changes.
      Click on the configure icon in the Connection preferences column, set the poll interval and click on SAVE POLL INTERVAL.

      Set config JSON poll interval

    • Webhook notification​

      You can set up automatic webhook notifications about feature flag changes for your Proxy by providing its public URL.
      Click on the configure icon in the Connection preferences column and select Webhook notification. Then, enter your Proxy instance's public URL and click ADD PROXY URL.

      Set Proxy webhook URL

      Put the displayed webhook signing key(s) into your Proxy's configuration. Signing keys are for making sure that webhook requests received by your Proxy are sent by ConfigCat. Signatures are automatically verified by the Proxy.

      Copy webhook signing key
      options.yml
      profile:
        webhook_signing_key: <signing-key>

      Test the connection to your Proxy instance.

      Test the webhook configuration

  • OptionDefaultDescription
    profile:
      key: "<key>"
    		-The Proxy profile's key.
    profile:
      secret: "<secret>"
    		-The Proxy profile's secret used by the Proxy to authenticate requests to the Public Management API.
    profile:
      base_url: "<base-url>"
    		ConfigCat Public Management API URLThe base URL from where the Proxy should fetch the SDK Keys selected in the connected Proxy profile.
    profile:
      poll_interval: 300
    		300The interval (in seconds) specifying how frequently the Proxy should poll for changes in the connected Proxy profile.
    profile:
      webhook_signing_key: "<signing-key>"
    		-The key used to sign the webhook requests sent to the Proxy. More about how to set up webhooks for a Proxy profile.
    profile:
      webhook_signature_valid_for: 300
    		300The time period (in seconds) within which webhook requests are considered valid. More about how to set up webhooks for a Proxy profile.
    profile:
      log:
        level: "<error|warn|info|debug>"
    		warnThe verbosity level for Proxy profile-related logging.
    Possible values: error, warn, info, or debug.
    profile:
      sdks:
        base_url: "<sdk-base-url>"
    		ConfigCat's CDN URL.The CDN base URL (forward proxy, dedicated subscription) from where the ConfigCat SDKs should download the config JSON.
    profile:
      sdks:
        log:
          level: "<error|warn|info|debug>"
    		warnThe verbosity level for logging performed by the ConfigCat SDKs spawned for the connected Proxy profile.
    Possible values: error, warn, info, or debug.

    Profile caching​

    Proxy instances running in online mode are caching their connected profile if they have a cache configured. This means that other Proxy instances running with global offline mode enabled can use those cached profiles from the same shared cache.

    info

    Offline Proxy instances only need the profile's key to read the connected profile from the cache, the secret option is not mandatory in this mode.

2. Manual configuration​

When using environment variables, the SDK keys can be specified as a JSON object, where the property name is the SDK identifier (the identifier of the config/environment pair whose SDK Key the underlying SDK instance is configured to use) and the property value is the actual SDK key. The SDK identifier part is later used in endpoint routes to recognize which SDK must serve the given flag evaluation request.

Furthermore, when configuring the Proxy via environment variables, the identifier becomes a part of the SDK specific environment variable's name in the following format: CONFIGCAT_<SDK_ID>_<OPTION>.

For example, suppose we have the following setup: CONFIGCAT_SDKS={"my_sdk":"<your-sdk-key>"}.
In this case, the environment variable that sets the corresponding SDK instance's poll interval will be named as follows: CONFIGCAT_MY_SDK_POLL_INTERVAL.

info

The SDK identifier part of the environment variables is always transformed to uppercase and each hyphen (-) character is replaced with underscore (_).

In case of a YAML file, the SDK identifier is the property name set under the sdks node.

options.yml
sdks:
  my_sdk:
    ...

This is the whole YAML section of the SDK specific options.

options.yml
sdks:
  my_sdk:
    key: "<your-sdk-key>"
    base_url: "<base-url>"
    poll_interval: 60
    data_governance: <"eu"|"global">
    webhook_signing_key: "<key>"
    webhook_signature_valid_for: 300
    default_user_attributes:
      attribute_key: "<attribute_value>"
    log:
      level: "<error|warn|info|debug>"
    offline:
      log:
        level: "<error|warn|info|debug>"
      enabled: <true|false>
      use_cache: <true|false>
      cache_poll_interval: 5
      local:
        file_path: "./path/local.json"
        polling: <true|false>
        poll_interval: 5
  another_sdk:
    ...

Here's the explanation for each option:

SDK Identifier / SDK Key mapping​

OptionDescription
my_sdk:
  key: "<your-sdk-key>"
The SDK identifier and the associated SDK key.

Additional options for underlying SDKs​

OptionDefaultDescription
my_sdk:
  base_url: "<base-url>"
ConfigCat's CDN URL.The CDN base URL (forward proxy, dedicated subscription) from where the SDK should download the config JSON.
my_sdk:
  poll_interval: 60
60The underlying SDK's polling interval in seconds.
my_sdk:
  data_governance: "<global|eu>"
globalDescribes the location of your feature flag and setting data within the ConfigCat CDN. This parameter needs to be in sync with your Data Governance preferences. More about Data Governance.
my_sdk:
  webhook_signing_key: "<key>"
-The key used to sign the webhook requests sent to the Proxy. More about the webhook endpoint.
my_sdk:
  webhook_signature_valid_for: 300
300The time period (in seconds) within which webhook requests are considered valid. More about the webhook endpoint.
my_sdk:
  default_user_attributes:
    attribute_key: "<attribute_value>"
-Additional SDK specific default user attributes. The Proxy will use these attributes when an evaluation request doesn't contain a value for the predefined attribute.
When there's a default value defined for the same attribute at both SDK and global level, the one at the SDK level will take precedence.
my_sdk:
  log:
    level: "<error|warn|info|debug>"
warnThe verbosity level for logging performed by the underlying SDK.
Possible values: error, warn, info, or debug.

Offline Mode​

The following options are specific to the SDK's offline mode. In offline mode, there are two ways the Proxy can provide the underlying SDKs with the data required for feature flag evaluation.

  • Polling a cache: The Proxy can poll a cache for feature flag changes. It can use a shared cache that an online Proxy instance writes to. More about the cache option.
  • Watching / polling a file: The Proxy can watch or poll for modifications in a file that contains data for feature flag evaluation. For watching, the Proxy uses the fsnotify library.
OptionDefaultDescription
my_sdk:
  offline:
    enabled: <true|false>
falseTurns the SDK's offline mode on/off. In offline mode, the SDK will not communicate with the ConfigCat CDN network. Instead, it uses the configured cache or a file as the source of its config JSON.
my_sdk:
  offline:
    use_cache: <true|false>
falseControls whether the SDK should use the configured cache as the source of its config JSON. More about the cache option.
my_sdk:
  offline:
    cache_poll_interval: 5
5The cache polling interval in seconds. Used only, when the use_cache option is true. More about the cache option.
my_sdk:
  offline:
    log:
      level: "<error|warn|info|debug>"
warnThe verbosity level for offline mode-related logging.
Possible values: error, warn, info or debug.
my_sdk:
  offline:
    local:
      file_path: "./path/local.json"
-Path to the local file that contains the config JSON to use for feature flag evaluation.
my_sdk:
  offline:
    local:
      polling: <true|false>
falseControls whether the Proxy should use polling instead of file system watching for monitoring the local file for changes.
my_sdk:
  offline:
    local:
      poll_interval: 5
5The interval to use for polling the local file in seconds.

Default User Attributes​

There's an option to predefine User Object attributes with default values. Whenever the Proxy receives an evaluation request, it will automatically attach these predefined attributes to the request. If the evaluation request contains a different value for an attribute you previously defined, the request's value will take precedence.

default_user_attributes:
  attribute_key1: "<attribute_value1>"
  attribute_key2: "<attribute_value2>"
info

It's also possible to set default user attributes at the SDK level. See the SDK options section above for more details.

Global Offline Mode​

It is possible to turn on offline mode globally for a whole Proxy instance. When it's turned on, each underlying SDK switches to work from the configured cache.

OptionDefaultDescription
offline:
  enabled: <true|false>
falseTurns the global offline mode on/off.
offline:
  cache_poll_interval: 5
5The cache polling interval in seconds. More about the cache option.
offline:
  log:
    level: "<error|warn|info|debug>"
warnThe verbosity of the offline mode related logs.
Possible values: error, warn, info or debug.
note

When an SDK also has its offline option set, that will override what it would inherit from the global offline option.

Cache​

The Proxy in its default setup stores all the information it needs for feature flag evaluation in memory. This behavior is extendable with an external cache that you can use for pointing the underlying SDKs to your own data storage.

Currently, Redis, MongoDB, and DynamoDB is supported as external cache. The cache key for the underlying SDKs is based on the SDK Key. This means that multiple Proxy instances using the same SDK key will read/write the same cache entry.

info

The ConfigCat Proxy supports shared caching, which means it can feed an external cache that is shared by other ConfigCat SDKs. You can read more about this feature and the required minimum SDK versions here.

Shared cache architecture

Redis​

This is the whole YAML section of the Redis specific options.

options.yml
cache:
  redis:
    enabled: <true|false>
    db: 0
    user: "<user>"
    password: "<pass>"
    addresses: ["<addr1>", "<addr2>"]
    tls: 
      enabled: <true|false>
      min_version: <1.0|1.1|1.2|1.3>
      server_name: "<server-name>"
      certificates:
        - cert: "<path-to-cert>"
          key: "<path-to-key>"

Here's the explanation for each option:

OptionDefaultDescription
cache:
  redis:
    enabled: <true|false>
falseTurns caching into Redis on/off.
cache:
  redis:
    addresses: ["<addr1>", "<addr2>"]
["localhost:6379"]The addresses of the Redis instances. The Proxy uses Universal Redis clients, so if the array contains multiple addresses, it will use a ClusterClient instance.
cache:
  redis:
    db: 0
0The selected Redis database.
cache:
  redis:
    user: "<user>"
-The username for connecting to Redis.
cache:
  redis:
    password: "<pass>"
-The password for connecting to Redis.

The following options are for securing the connection to Redis with TLS.

OptionDefaultDescription
cache:
  redis:
    tls: 
      enabled: <true|false>
falseTurns the TLS connection to Redis on/off.
cache:
  redis:
    tls: 
      min_version: <1.0|1.1|1.2|1.3>
1.2The minimum TLS version to use.
cache:
  redis:
    tls: 
      server_name: "<server-name>"
-The name of the Redis server.
cache:
  redis:
    certificates:
      - cert: "<path-to-cert>"
        key: "<path-to-key>"
-A list of TLS certificate/key pairs.

MongoDB​

When the configured MongoDB database and collection doesn't exist, the Proxy automatically creates them. The following document structure is used to store the downloaded config JSON in BSON format:

{ 
  "key": "<The unique cache key determined by the ConfigCat SDK within the Proxy>", 
  "payload": "<The downloaded config JSON in a standardized format determined by the ConfigCat SDK within the Proxy>" 
}

At the collection creation, the Proxy also creates a unique index for the key field.

This is the whole YAML section of the MongoDB specific options.

options.yml
cache:
  mongodb:
    enabled: <true|false>
    url: "<connection-url>"
    database: "<database-name>"
    collection: "<collection-name>"
    tls: 
      enabled: <true|false>
      min_version: <1.0|1.1|1.2|1.3>
      server_name: "<server-name>"
      certificates:
        - cert: "<path-to-cert>"
          key: "<path-to-key>"

Here's the explanation for each option:

OptionDefaultDescription
cache:
  mongodb:
    enabled: <true|false>
falseTurns caching into MongoDB on/off.
cache:
  mongodb:
    url: "<connection-url>"
-The connection url to MongoDB.
cache:
  mongodb:
    database: "<database-name>"
configcat_proxyThe name of the MongoDB database that the Proxy will use for storing data.
cache:
  mongodb:
    collection: "<collection-name>"
cacheThe name of the collection inside the MongoDB database.

The following options are for securing the connection to MongoDB with TLS.

OptionDefaultDescription
cache:
  mongodb:
    tls: 
      enabled: <true|false>
falseTurns the TLS connection to MongoDB on/off.
cache:
  mongodb:
    tls: 
      min_version: <1.0|1.1|1.2|1.3>
1.2The minimum TLS version to use.
cache:
  mongodb:
    tls: 
      server_name: "<server-name>"
-The name of the MongoDB server.
cache:
  mongodb:
    certificates:
      - cert: "<path-to-cert>"
        key: "<path-to-key>"
-A list of TLS certificate/key pairs.

DynamoDB​

By default, the Proxy uses the standard AWS CLI environment variables (or a local AWS configuration file) to read the AWS credentials and region for connecting to DynamoDB.

The Proxy doesn't create the DynamoDB table automatically, it must already exist with a partition key called key. The data stored in the table has the following attributes:

  • key: The unique cache key determined by the ConfigCat SDK within the Proxy.
  • payload: The downloaded config JSON in a standardized format determined by the ConfigCat SDK within the Proxy.

The following permissions are needed to read and write the table:

  • GetItem
  • PutItem

This is the whole YAML section of the DynamoDB specific options.

options.yml
cache:
  dynamodb:
    enabled: <true|false>
    url: "<url>"
    table: "<table-name>"

Here's the explanation for each option:

OptionDefaultDescription
cache:
  dynamodb:
    enabled: <true|false>
falseTurns caching into DynamoDB on/off.
cache:
  dynamodb:
    url: "<url>"
-The DynamoDB service endpoint.
cache:
  dynamodb:
    table: "<table-name>"
configcat_proxy_cacheThe name of the DynamoDB table that the Proxy will use for storing data.

HTTP​

The following HTTP and HTTP Proxy related options are available:

options.yml
http:
  enabled: <true|false>
  port: 8050
  log: 
    level: "<error|warn|info|debug>"
  status:
    enabled: <true|false>

http_proxy:
  url: "<proxy-url>"

Here's the explanation for each option:

OptionDefaultDescription
http: 
  enabled: <true|false>
trueTurns the main HTTP server on/off. This server hosts the CDN proxy, API, SSE, and webhook endpoints.
http:
  port: 8050
8050The main HTTP server's port.
http:
  log:
    level: "<error|warn|info|debug>"
warnThe verbosity of the HTTP related logs.
Possible values: error, warn, info, or debug.
When debug is set, the Proxy will log each HTTP request with additional details.
http:
  status: 
    enabled: <true|false>
falseTurns the hosting of the status endpoint on the main HTTP port (default: 8050) on/off.

HTTP Proxy​

OptionDefaultDescription
http_proxy:
  url: "<proxy-url>"
-The network proxy's URL that the ConfigCat Proxy must use for communication through the internet.

Endpoints​

The options for HTTP endpoints are discussed in the Endpoints section.

TLS​

For securing direct communication to the ConfigCat Proxy, you have the option to set up TLS. Another option would be to use a full-featured reverse proxy that secures the communication and forwards each request to the Proxy.

The following options are for the first scenario where you secure the direct HTTP and gRPC communication.

options.yml
tls: 
  enabled: <true|false>
  min_version: <1.0|1.1|1.2|1.3>
  certificates:
    - cert: "<path-to-cert>"
      key: "<path-to-key>"

Here's the explanation for each option:

OptionDefaultDescription
tls: 
  enabled: <true|false>
falseTurns the enforcement of TLS connection to the ConfigCat Proxy on/off.
tls: 
  min_version: <1.0|1.1|1.2|1.3>
1.2The minimum TLS version to accept.
tls:
  certificates:
    - cert: "<path-to-cert>"
      key: "<path-to-key>"
-A list of TLS certificate/key pairs.

Logging​

The Proxy supports the following log levels: debug, info, warn, and error. The default is warn.

You can specify the log level either globally or for each individual component. If you don't set a component's log level explicitly, it will inherit the global level's value.

log:
  level: "<error|warn|info|debug>"
info

When the main HTTP server's or gRPC server's log level is set to debug, each HTTP request or RPC the Proxy receives is logged with additional details. (duration, response status, etc.)