Skip to main content

1.5.40

Released 12 August 2026

Rollback, rebuilt as one mechanism. Rolling back used to mean something different in every module — a backup file here, a stored copy there, a version restore somewhere else. Now it means one thing everywhere: re-deploy an earlier retained version of the certificate through the same path a normal deployment takes, and you choose exactly which version goes out.

New

  • Rollback for every distribution module, with a version picker — Rollback opens a list of retained versions, newest first, with ineligible ones greyed out and the reason shown. All fifteen modules can roll back, including Webhook and SMTP — for those two it means re-sending the earlier version, not recalling the one already delivered.
  • See why a rollback is not available — A per-version eligibility list tells you which versions you can roll back to, and why the others are excluded: it is the current version, it has expired, its private key is no longer retained, the module cannot roll back, or it falls under Cloudflare's 14-day remaining-validity floor.
  • Roll Forward — When a certificate renews while a distribution is still rolled back, the row is tagged accordingly and the Run button becomes Roll Forward, which deploys the current certificate and clears the rolled-back state.
  • Version numbers in certificate history — The Certificates tab shows a version column (v1, v2, …) — the same numbers the rollback picker uses — and a download of an older version is named with its version instead of an opaque identifier.
  • Revoke a single historical version — A superseded version can be revoked at the CA without retiring the live certificate. Revoked versions are then automatically excluded from rollback.
  • Per-host deploy timeout for Windows/IIS targets — An optional limit on how long one host may take for its whole upload → import → bind → validate cycle, so a single hung machine no longer consumes the entire job's budget.
  • Clearer rollback outcomes — Failed, cancelled, not-applied and not-queued rollbacks each come with an explanation of the state your targets are likely in and what to do next.

Improved

  • The distribution list is much lighter — Per-target results are no longer sent with every row; they load when you expand one. The certificate detail page also stopped polling the same data twice.
  • Auto-rollback notifications say more — They now name the certificate version that was deployed, the module type, and the job that triggered it.
  • Audit entries name the real person — Job-driven audit records used to be attributed to "system" even when an operator started them.
  • Faster history and queue queries — Certificate history, rollback eligibility and job pickup are now backed by proper indexes; on busy installations these previously scanned entire collections.
  • Secrets stay out of post-deploy logs — Secret project variables used by post-deploy commands are redacted from job logs and error text, so a remote error that echoes the command line cannot reveal them.

Changed behaviour

  • Downloads only include the private key when the format calls for it. Previously every format also carried the key in PEM form. Now cert, chain and fullchain return public material only, while pfx, jks and der carry the key inside their own container. pem, key, bundle and all are unchanged. Scripts that relied on extracting a key from a fullchain download need updating.
  • Rollback no longer depends on module-specific snapshots. SSH stops writing .bak files (existing ones are inert and can be deleted), the Kubernetes "store content" option is gone, Vault no longer requires KV v2, and Exchange and MerlinCDN can roll back even when "delete old certificate" was on. Everything now comes from the platform's own version history.
  • Post-deploy validation runs after a rollback too, confirming the version you rolled back to is the one actually being served.
  • Rollback is stricter about when it will run — one at a time per distribution, never while a fan-out is in progress, never on a certificate that is not active, and never on a distribution that has not deployed anything yet.
  • Auto-rollback fires in fewer situations — only when a run finished failed or partial and at least one target actually changed; never for fanned-out runs; and never for Webhook or SMTP, where re-sending an older certificate after a transient error would surprise the recipient. While auto-rollback applies, the failed run is not also auto-retried, so the system cannot ping-pong between pushing and rolling back.
  • The rolled-back state is sticky. Background sweeps will not re-push the current certificate while a distribution is rolled back; it clears on the next renewal, or when you run or roll forward manually.
  • Workers process four jobs in parallel by default, where the effective default used to be one. Per-certificate and per-device locks still serialise anything that would genuinely conflict.
  • History pruning runs on every certificate write — issuance and import as well as renewal — and any version a distribution still references (deployed, rolled back to, or pending a rollback) is never pruned.
  • A contended device is retried, not failed. A batch that waits out the full device-lock window is re-queued once after five minutes; a second timeout is final.
  • Azure Key Vault imports are encrypted in transit to the vault, using a strong random password per import instead of a password-free container.

Fixed

  • Editing a module in the UI silently discarded settings made through the API. Saving the form dropped values it does not render — webhook headers, concurrency, per-target timeouts, target overrides. They are now preserved.
  • Clearing a target's credential did nothing. Removing the credential and saving left the target authenticating with the old one.
  • Validation endpoints lost their history on every save. Each save minted new endpoint identifiers, orphaning the results recorded against previous runs.
  • A post-deploy reload could be skipped forever. If a worker died between writing the certificate files and running the post-deploy action, later runs saw the files as unchanged and never re-ran the reload. The action now repeats until it has actually succeeded.
  • An interrupted Windows file transfer could leave no file at all. Transfers deleted the destination before uploading; they now stage the upload and swap it into place, so a killed transfer leaves the existing file intact.
  • A rollback whose status write failed reported success. It now fails loudly and retries, instead of leaving a distribution that looks rolled back but is not recorded as such.
  • Distributions could show "Rolling back…" forever. A scheduler sweep now closes out rollback jobs that died and releases the certificate version they pinned.
  • A retried job could collide with its own earlier attempt on the same appliance or Windows host, because the reclaimed job inherited locks the previous attempt still held.
  • A successful run kept displaying the previous failure's error text.
  • IIS and Exchange no longer embed the certificate container's password in the remote command. It travels as a separate, access-restricted file and is cleaned up afterwards, including after a cancellation or timeout.
  • A confusing message when an old version could not be decrypted. Downloading a historical version whose encryption key version is no longer configured claimed a renewal was in progress; it now names the missing key version and what to restore.
  • Bulk renew left a stale certificate list and could show its success message twice.