The Mercure Hub is configurable using environment variables (recommended in production, twelve-factor app methodology), command line flags and configuration files (JSON, TOML, YAML, HCL, envfile and Java properties files are supported).
Environment variables must be the name of the configuration parameter in uppercase.
./mercure -h to see all available command line flags.
Configuration files must be named
mercure.yaml) and stored in one of the following directories:
- the current directory (
~/.config/mercure/(or any other XDG configuration directory set with the
Most configuration parameters are hot reloaded: changes made to environment variables or configuration files are immediately taken into account, without having to restart the hub.
When using environment variables, list must be space separated. As flags parameters, they must be comma separated.
|the directory where to store Let's Encrypt certificates|
|a list of hosts for which Let's Encrypt certificates must be issued|
|the address used by the acme server to listen on (example: |
|the address to listen on (example: |
|allow subscribers with no valid JWT to connect|
|a cert file (to use a custom certificate)|
|a key file (to use a custom certificate)|
|Usedisable HTTP compression support|
|a list of allowed CORS origins, can be |
|debug mode, dangerous, don't enable in production (logs updates' content, why an update is not send to a specific subscriber and recovery stack traces)|
|demo mode (automatically enabled when |
|maximum duration of the dispatch of a single update, set to |
|expose the subscription web API and dispatch private updates when a subscription between the Hub and a subscriber is established or closed. The topic follows the template |
|interval between heartbeats (useful with some proxies, and old browsers), set to |
|the JWT key to use for both publishers and subscribers|
|the JWT verification algorithm to use for both publishers and subscribers, e.g. |
|the log format, can be |
|Enable the |
|if metrics are enabled, the login of the allowed user to access the |
|if metrics are enabled, the password of the allowed user to access the |
|a list of origins allowed to publish (only applicable when using cookie-based auth)|
|must contain the secret key to valid publishers' JWT, can be omitted if |
|the JWT verification algorithm to use for publishers, e.g. |
|maximum duration for reading the entire request, including the body, set to |
|must contain the secret key to valid subscribers' JWT, can be omitted if |
|the JWT verification algorithm to use for subscribers, e.g. |
|URL representation of the history database. Provided database are |
|use the |
|maximum duration before timing out writes of the response, set to |
acme_hosts or both
key_file are provided, an HTTPS server supporting HTTP/2 connection will be started.
If not, an HTTP server will be started (not secure).
When using RSA public keys for verification make sure the key is properly formatted.
-----BEGIN PUBLIC KEY----- MIGeMA0GCSqGSIb3DQEBAQUAA4GMADCBiAKBgHVwuJsFmzsFnOkGj+OgAp4lTNqR CF0RZSmjY+ECWOJ3sSEzQ8qtkJe61uSjr/PKmqvBxxex0YtUL7waSS4jvq3ws8Bm WIxK2GqoAVjLjK8HzThSPQpgv2AjiEXD6iAERHeySLGjYAUgfMrVJ01J5fNSL+O+ bCd7nPuNAyYHCOOHAgMBAAE= -----END PUBLIC KEY-----
JWT_KEY=`cat jwt_key.pub` ./mercure
$env:JWT_KEY = [IO.File]::ReadAllText(".\jwt_key.pub")
|name of the bolt bucket to store events. default to |
|chances to trigger history cleanup when an update occurs, must be a number between |
|size of the history (to retrieve lost messages using the |
Below are common examples of valid DSNs showing a combination of available values:
# absolute path to `updates.db` transport_url="bolt:///var/run/database.db" # path to `updates.db` in the current directory transport_url="bolt://database.db" # custom options transport_url="bolt://database.db?bucket_name=demo&size=1000&cleanup_frequency=0.5"