Configuration

db.url - the jdbc url of the database server.

db.username - the username used to log in.

db.password - the password for the user

db.minConnections - the minimum number of connections to hold open (default 3)

db.maxConnections - the maximum connections to open to the db (default 100)

db.pstmtCacheSize - the prepared statement cache size (no default)

nats.enabled=false

cloudevents.pubsub.enabled=true

cloudevents.pubsub.project=featurehub - whatever the Google project ID you are deploying FeatureHub into

cloudevents.edge-mr.pubsub.topic-name=featurehub-edge-updates - the name of the topic used by Edge to publish TestSDK updates back to MR

cloudevents.mr-edge.pubsub.topic-name=featurehub-mr-edge - Feature Updates published from MR → Edge for streaming clients

cloudevents.stats.pubsub.topic-name=featurehub-stats - You only need to configure this if you have Stats publishing turned on, otherwise you can ignore it

cloudevents.mr-dacha2.pubsub.topic-name=featurehub-mr-dacha2 - the name of the topic MR publishes feature updates, environment updates and service account updates.

cloudevents.pubsub.min-backoff-delay-seconds=5 - Edge and Dacha must be able to create their own subscriptions. Google PubSub is not actually "pubsub", there is no way for all connections to a subscription to receive a message, so this delay reflects how long PubSub should wait before trying to redeliver the message. Edge and Dacha will delete their subscriptions when they shut down, so keep this low.

cloudevents.mr-edge.pubsub.subscription-prefix=featurehub-edge-listener - the prefix used for subscriptions created by Edge

cloudevents.mr-dacha2.pubsub.subscription-prefix=featurehub-dacha2-listener - the prefix used for subscriptions created by Dacha2 instances

cloudevents.inbound.channel-names=featurehub-edge-updates-mr-sub

passwordsalt.iterations (1000) - how many iterations it will use to salt passwords

cache.pool-size (10) - how many threads it will allocate to publishing changes to Dacha and SSE

feature-update.listener.enable (true) - whether this MR should listen to the same topic as the Dacha’s and respond if they are empty

environment.production.name (production) - the name given to the automatically created production environment. It will be tagged "production".

environment.production.desc (production) - the description field for same.

register.url [deprecated] - the url used for registration. The front-end should strip the prefix off this and add its own relative one. The format has to be register.url=http://localhost:8085/register-url?token=%s - if your site is https://some.domain.info for example, it would be register.url=https://some.domain.info/register-url?token=%s. This is honoured but no longer required and it is recommended to be removed.

portfolio.admin.group.suffix ("Administrators") - the suffix added to a portfolio group when a portfolio is created for the first time, it needs an Admin group. So a portfolio called "Marketing" would get an admin group called "Marketing Administrators" created.

web.asset.location=/var/www/html/intranet - can be set optionally if you are intending to serve the Admin web app on the intranet without public internet access. We supply this application build already preloaded with all necessary assets. Available in FeatureHub v1.5.4 and higher. With 1.5.10 or higher there is - web.asset.location=/var/www/html/html - which can be used if there is a lot of mobile use.

cache-control.web.index - this allows you to set the Cache-Control header on the index.html file. It is set by default to no-store, max-age=0 preventing any caching, so as new versions roll out, they are correctly picked up.

cache-control.web.other - this sets the cache control on all of the other content of the website, which is essentially considered to be versioned. This data should never change and it is set by default to max-age=864000 - or about 10 days.

webhooks.features.enabled - enables webhooks functionality. True by default. Note, internally webhooks are dependent on enrichment pipeline, see below for enricher.enabled property. If this property is set to false, then it will override webhooks.features.enabled property. To disable webhooks, set webhooks.features.enabled=false This will remove webhooks functionality from the Admin UI. Depending on the installation option, webhooks may require additional configuration as described here

webhook.features.max-fails - number of webhook retries before disabling. When webhooks fail to connect and deliver their result - any HTTPS status outside of the 200 range (including 0 - where a connection is refused) then the FeatureHub app begins a countdown, where after n number of retries, it will automatically disable the webhook. Default value is 5. To change, set to the desired number: webhook.features.max-fails=10

enricher.enabled - The enricher pipeline, currently only required to be enabled for webhooks to work. True by default. To reduce unnecessary "load" if you do not use webhooks, disable as follows: enricher.enabled=false

ga.tracking-id - If provided, this will enable tracking on the usage of your Admin UI and tell you what features people are using.

mr.dacha2.api-keys - This swaps the Dacha2 endpoint to the public interface and protects it to expect a key header with one of the keys listed here. See Dacha2 below for more details.

cache.timeout - how long the server will attempt to find and resolve a master cache before moving onto the next step (in ms, default = 5000)

cache.complete-timeout - how long it will wait after another cache has negotiated master before it expects to see data (in ms, default = 15000)

cache.pool-size - the number of threads in pool for doing "work" - defaults to 10

management-repository.url - http(s) location of the Management Repository. Needs to include a port number.

dacha2.cache.api-key - this is used to allow Dacha2 to communicate with a Remote Management Repository to get its cache misses. If an Edge request comes in that Dacha2 hasn’t seen, it will make a request to the Management Repository to get the state - which is a fairly heavy call. This call you don’t normally want to expose over the internet as it can be a vector of denial of service attack on your Management Repository. If you in fact wish to distribute your Dacha2 instances out to several clusters, potentially across the world, then you can protect the MR API by setting mr.dacha2.api-keys (as outlined above) which gives you (a) the ability to rotate keys and (b) different potential keys for each cluster and this key dacha2.cache.api-key on your Dacha2 instances. By setting the mr.dacha2.api-keys value, the API will swap to the public interface and will not be available internally. Note, this traffic need not going through the external load balancer for Dacha2 instances in the same cluster as the Management Repository. The following diagram shows this in more detail.

listen.pool-size (10) - how many threads to allocate to processing incoming requests to listen. This just takes the request, decodes it and sends it down via NATs and releases.

edge.sse.drop-after-seconds (30) - how many seconds a client is allowed to listen for before being kicked off. Used to ensure connections don’t go stale. This was previously named maxSlots and a valid in that field is recognized.

edge.dacha.delay-slots (10) - if Dacha is unavailable because it does not have a full cache, it will reject the request. For SSE, this creates a sliding window of a random delay in seconds, meaning a connection will be dropped in 1-10 seconds (by default). This is designed to prevent reconnect storms as infrastructure is restarted.

edge.sse.heartbeat-period (0) - if defined, Edge will attempt to send heartbeat signals down the SSE connection for the duration of the connection while it is alive. If you set edge.sse.drop-after-seconds to 0, then the SSE connection will stay open, sending heartbeat signals until the remote system drops the connection. This allows the heartbeat to be used as well as or instead of kicking SSE connections off to ensure ghost connections.

dacha.url.default = url - You MUST specify this for Dacha2 this is only relevant if you are running split servers - so Dacha and Edge run in their own containers. You need to tell Edge where Dacha is located. In the sample docker-compose where they are split, the hostname for Dacha is dacha, so this is dacha.url.default=http://localhost:8034. This isn’t required for the Party Server because communication is internal.

monitor.port (undefined) - if not defined or 0, it will expose the metrics and health on the server port. If not, it will expose them on this port (and not on the server port). For systems like ECS where having > 1 port is not desirable, you should set it to 0.

featurehub.url-path - allows to configure base path (context root) other than "/". This will set the base path in the index.html of the FeatureHub web app and the backend. Note, this is an offset, not a full domain name, e.g. featurehub.url-path=/foo/featurehub. In case if the front-end is decoupled on a CDN, the base bath needs to be configured directly in index.html by setting: <base href="/foo/featurehub/"> (note the trailing slash).

cache-control.api - allows the configuration of the Cache-Control headings on all GET based API calls. This allows you to put a CDN in front of FeatureHub and ensure the CDN does not cache any headers. It is on by default. See also the cache-control.web configuration for MR and Party Server.

cache-control.api.enabled - set this to false if you wish to disable the Cache Control headers for APIs.

connect.logging.environment - this is a comma separated value list that lets you pick up values from environment variables that get added directly to your logs. It is typically used in Kubernetes deploys to allow you to extract information from the k8s deploy and put it in environment variables and have them logged. The format is <ENV-VAR>=<log-key>. You can use . notation to split it into objects.

opentelemetry.valid-baggage-headers - this allows you to filter out the valid W3C Baggage headers that you will accept from incoming clients. The Web UI adds its own (the request-id for that session) and the server adds in the UUID of the user who is performing the action. Your clients can add anything further they wish to baggage headers, but you need to specify them here to allow them to be added to the baggage. The side effect of this is that all baggage will be logged in the logs. This gives you very good OpenTelemetry and log level tracebility for actions from clients.

audit.logging.web.header-fields - a comma separated list of fields that will be extracted out of each web request and put into a field in the JSON logs output by the server. All headers are grouped into an object called http-headers. Headers by definition are case insensitive. Available from 1.5.5. An example:

audit.logging.user - if this is set to true (it is false by default) then the user’s ID and email will be logged against each of their requests where it is known. It appears in a user object with id and email as components. Available from 1.5.5. An example

server.port (8903) - the server port that the server runs on. it always listens to 0.0.0.0 (all network interfaces)

server.gracePeriodInSeconds (10) - this is how long the server will wait for connections to finish after it has stopped listening to incoming traffic

jersey.exclude

jersey.tracing

jersey.bufferSize (8k) - how much data of a body to log before chopping off

jersey.logging.exclude-body-uris - urls in which the body should be excluded from the logs

jersey.logging.exclude-entirely-uris - urls in which the entire context should be excluded from the logs. Typically you will include the /health/liveness and /health/readyness API calls along with the /metrics from this. You may also wish to include login urls.

jersey.logging.verbosity - the default level of verbosity for logging HEADERS_ONLY, - PAYLOAD_TEXT, - PAYLOAD_ANY

/health/liveness

/health/readyness