Mercure

A browser showing live order status or a changing dashboard needs to receive new information without repeatedly asking whether anything changed. Mercure provides a protocol and a hub for sending those updates over HTTP connections. The application publishes an update, and the hub forwards it to authorized subscribers. It is useful when several clients need timely changes from an API, with connection recovery and access to each topic planned explicitly.

Current guidance

Mercure is a protocol for server-sent updates and a hub implementation built with Caddy. Current upstream installation documentation provides its own Helm repository, distinct from the deprecated central stable chart. The hub, application publisher and subscribing client each have a separate role in successful delivery.

Configure publisher and subscriber JWT keys deliberately, and do not reuse the example secrets. The documented development configuration enables anonymous subscriptions and a debug interface; those conveniences should not accidentally define a private production channel’s access policy. Align TLS termination and public hub URLs with the application and browser environment.

Long-lived event streams make proxy timeouts, rolling shutdown and reconnect behavior important. The upstream chart documents stream-aware rollout settings and defaults to one replica with BoltDB history stored locally to that pod. Increasing the replica count alone does not share history or deliver a publication on one pod to subscribers on another; ordinary multi-replica deployments need a transport that synchronizes between pods. Verify reconnection, authorized topic access and the behavior after a restart with the selected storage and transport configuration. This review confirms current upstream packaging but does not promise exactly-once delivery or certify every high-availability topology.