Release Notes

mod_pagespeed 2.1 is the converged line: the native web-server module for Apache and nginx, with the ModPageSpeed 2.0 engine running alongside it as a separate optimizer worker — one product again. The current stable release is 2.1.0. We recommend running the latest release: it always carries the most recent performance and security work.

What’s in mod_pagespeed 2.1

The module and the optimizer worker

• A drop-in for existing configurations. The module keeps the pagespeed directive surface and the 1.14/1.15 filter names, so an existing mod_pagespeed configuration carries over — swap the packages and your configuration carries with them. See the upgrade guide.
• The 2.0 engine, off the request path. The heavy work — image transcoding to WebP and AVIF, critical CSS, ML-predicted image quality with quality verification, variant-aware caching, zero-copy serving — runs in the pagespeed-optimizer worker, and the module serves the results from the shared cache.
• One feature set, on every platform. Browser-based analysis (critical CSS validation, waterfall capture, visual comparison) and the agent-readability tooling — agent_optimize markdown variants and the synthesized llms.txt index — ship for everyone, enabled by their operator flags alone.
• A matching pair, installed as one. On the deb and rpm channels the module and the pagespeed-optimizer worker install and upgrade together from the same signed repository, and a version mismatch between them is reported loudly instead of being silently absorbed.

Hardened by default

The optimizer decodes untrusted bytes, so the 2.1 defaults assume the optimizer will be attacked:

• The worker runs as a dedicated unprivileged pagespeed system user with an empty capability set, and nothing it creates is world-accessible.
• The management API binds to loopback, requires a token when reachable remotely, and fails closed: remote is never unauthenticated. A group-scoped unix socket is the recommended local transport.
• Browser analysis requires the Chrome sandbox, and the packaged daemon runs under an enforcing system-call allow-list.
• The API token lives in a root-owned environment file rather than on the command line.
• No instance telemetry: the optimizer makes no outbound request of its own accord — the only egress is what the operator configures.

2.1.0 — 2026-09-17

The first general-availability release of the converged line, and the successor to both the ModPageSpeed 2.0 Docker/Helm line and mod_pagespeed 1.15.

Security and hardening — update recommended for every deployment moving to 2.1 from earlier release candidates or from the 2.0 line:

• Hardened: the optimizer daemon no longer runs as root on package installs. It runs as an unprivileged system user, the cache and socket permissions are closed to owner-plus-group, and the API token moved out of the process command line, where other local accounts could read it. This shrinks the impact of any future optimizer compromise.
• Hardened: the management API is no longer open by omission. A missing token now fails closed instead of serving without a credential, and headless Chrome no longer runs unsandboxed. Both are default flips with operator-visible remedies; the migration guide lists them.
• Hardened: the packaged daemon enforces its system-call allow-list by default, terminating on the first call outside it instead of only logging. Browser analysis ships a companion allow-list and works under enforcement with no extra step.

Changed (plan for this before you upgrade): the disk cache starts empty. This release moves the optimizer to a new on-disk cache format. Every deployment begins with a cold cache that refills as traffic arrives, so expect a temporary drop in cache hit rate and a matching rise in origin fetches. Check that the cache directory has room for the old and new volumes to coexist during the upgrade — keeping the old file is what makes a rollback warm. On package installs the worker keeps its cache in a versioned directory, and a package upgrade starts that cache cold by design. The migration guide has the full checklist.

Changed: mod_pagespeed 2.1 is licensed under the Apache License 2.0 — the same license the original codebase carried — and the relicensing is retroactive, covering the predecessor lines as well. The source is published at github.com/We-Amp/mod_pagespeed. Every feature is available to everyone, and the standard signed packages are free; what is for sale is support and hardened, attested builds.

Removed: instance telemetry. The daemon no longer derives a machine identifier and makes no outbound request of its own accord; the only egress is what the operator configures.

Added: the deb and rpm packages carry the hardened pagespeed-optimizer daemon — its service unit, permission model, and the client library the serving module binds — so the module and the worker upgrade as a matching pair.

The converged engine also carries the fixes from the 2.1 release candidates: cache-overwrite staleness fixes (a refreshed, replaced, or purged resource can no longer keep serving its superseded copy from memory), JavaScript and CSS minifier correctness fixes carried across both predecessor lines, image-quality verification hardening, and browser-analysis robustness under the unprivileged worker.

The predecessor lines

• Running ModPageSpeed 2.0? The Docker/Helm line is feature-frozen and supported until February 7, 2027; the ASP.NET Core middleware continues unchanged until the same date. The migration guide walks the move to 2.1, and the 2.0.x release history lives on the ModPageSpeed 2.0 release notes page.
• Running mod_pagespeed 1.15? 2.1 is its next release, and the upgrade is drop-in. 1.15 now receives security fixes only, for per-platform transition windows — see the upgrade guide and the 1.15 release notes.

Install and upgrade

mod_pagespeed 2.1 ships as native packages for Apache and nginx — the module and the pagespeed-optimizer worker from the same signed repository — as Docker images, and as a Helm chart. See Getting started to install, the installation guide for Docker, the Helm deployment guide for Kubernetes, and Deployment for production rollouts.

Reporting a security issue

Found a security problem? Please email security@we-amp.com so we can investigate and ship a fix. We publish security-relevant changes here as part of the regular release notes.