Mercure.rocks Security Policy

Maintaining a secure service is a continuous effort. This page describes the controls applied to Mercure Cloud and the practices followed by the open source Mercure Hub. To report a vulnerability, email contact+security@mercure.rocks.

Last updated: 2026-09-10.

#Data residency

Mercure Cloud's primary processing happens in the European Union:

• Hubs, application servers, database and cache: Amsterdam, Netherlands (DigitalOcean). Migrating to Scaleway, a French provider, over the coming months; processing stays in the EU.
• Encrypted nightly backups: Paris, France (AWS).

See Digital Sovereignty & Data Residency for the full breakdown.

#Encryption

• In transit. All client and inter-service traffic is encrypted with TLS via Caddy, with automatic certificate management. HTTP/2 and HTTP/3 are enabled by default. Modern cipher suites only.
• At rest. DigitalOcean managed services and the AWS S3 backup bucket encrypt data at rest using provider-managed keys.
• End-to-end (optional). Mercure supports JWE-encrypted update payloads, so even the Hub operator never sees plaintext when used.
• Authorization. Topic-level access is controlled by JWTs that you mint with your own private key.

#Network and infrastructure security

• Production runs on managed, audited European cloud infrastructure with modern network policy enforcement.
• Each tenant Hub is isolated. Hubs cannot reach each other or unrelated services.
• Workloads run as non-root with a restricted security context. Container images are rootless-compatible to fit hardened deployment standards.
• Operating systems and dependencies receive security patches as they become available.
• A strict minimum number of personnel have production access: Dunglas Services SAS and its French infrastructure-operations subcontractor, Les-Tilleuls.coop, bound by an Article 28 subprocessing agreement. All privileged access uses short-lived credentials with MFA.

#Backup and disaster recovery

• The full production state is backed up nightly to encrypted EU storage (AWS, Paris), on a different provider and in a different country from the primary infrastructure.
• The production database is backed up daily by the managed database provider, with continuous write-ahead-log archiving for point-in-time recovery.
• Backups retain for 31 days and are then automatically purged.
• Backups are encrypted at rest by the storage provider.
• Our Disaster Recovery Plan defines a quarterly restore-drill schedule covering both the cluster snapshots and database point-in-time recovery. Each drill is logged with its date, elapsed time and outcome, measured against the plan's recovery-time objectives.
• We maintain a written Disaster Recovery Plan and a written security risk assessment, both reviewed at least annually. Customers evaluating the Service can request them from contact@mercure.rocks.

#Vulnerability management

• Automated dependency and vulnerability scanning runs on every commit on the open source Hub and on this SaaS infrastructure.
• Reachability analysis of the binary that serves customer traffic, so triage is driven by whether vulnerable code can actually be called rather than by version numbers alone.
• Container image, infrastructure-as-code and committed-secret scanning on every push and pull request.
• Vulnerabilities are triaged on receipt and patched according to severity.
• To report one, see the vulnerability disclosure policy below.

#Personal-data breach notification

In the event of a personal-data breach likely to result in a risk to the rights and freedoms of natural persons, we notify the CNIL within 72 hours per GDPR Article 33, and notify affected users without undue delay per Article 34.

#Payments

Card data is handled by Stripe on PCI-DSS Level 1 infrastructure. We never store full card numbers on our servers; we only hold Stripe customer identifiers and invoice metadata.

#Open source and auditability

The Mercure protocol is an open IETF-style specification. The Hub's reference implementation is public on GitHub and MIT-licensed. You can audit the code, fork it, run it on your own infrastructure, or run Mercure Enterprise on any infrastructure of your choice for full data control.

#Subprocessors

See the Privacy Policy for the full list of subprocessors and the DPA for contractual safeguards.

#Vulnerability disclosure policy

We welcome reports from security researchers. If you follow this policy, we will not take legal action against you for your research.

#How to report

• Vulnerabilities in the open source Hub: GitHub Security Advisories, which keeps the report private until a fix ships. See also the project's SECURITY.md for supported versions.
• Vulnerabilities in Mercure Cloud, or anything you are unsure how to classify: contact+security@mercure.rocks.
• Machine-readable contact details: /.well-known/security.txt.

Include enough detail to reproduce the issue. English and French are both fine.

#What we commit to

These are targets for a small team, not contractual service levels. We would rather tell you a report is still open than let it go quiet, and we credit reporters who want credit.

#Scope

Covered by the authorisation below:

• api.mercure.rocks and the Mercure Cloud dashboard.
• Hubs we operate on mercure.rocks subdomains, tested against a hub in your own account.
• The open source Hub and Mercure Enterprise, tested on infrastructure you control.

Not covered:

• Deployments operated by a customer rather than by us, including custom domains pointing at hubs we host on their behalf. Ask that customer.
• Our subprocessors' own infrastructure. We cannot authorise testing of systems we do not operate. DigitalOcean, AWS, Auth0 and Stripe each run their own disclosure programmes.
• Denial of service, load testing, and anything that degrades the service for other users.
• Social engineering of our staff, subcontractors or customers, and attempts at physical access.
• Scanner output with no demonstrated impact.

#Safe harbour

If you make a good-faith effort to follow this policy, we consider your testing authorised. We will not bring or support any civil or criminal action against you for it. If a third party brings action against you for activity that complied with this policy, we will make it known that your actions were authorised.

This section exists because the authorisation is what makes research lawful: under French law, accessing a system without it is an offence (Code pénal art. 323-1). The authorisation covers the systems listed as in scope, and no others.

Good faith means: use only accounts and data that belong to you; stop at the first proof a vulnerability exists rather than exploring how much data you can reach; never modify or delete data that is not yours; never copy anyone else's personal data off our systems; and give us 90 days before public disclosure, or less if we ship a fix sooner and agree with you on the date.