The software is free. Support — and hardened builds — are what's for sale.

Yes. mod_pagespeed 2.1 is open source under the Apache License 2.0: free to install and run, in development and in production, with no usage registration. The standard signed packages cost nothing; what We-Amp sells is support — and hardened, attested builds.

Backing from the people who build the product: a direct channel, agreed response times for configuration, upgrade and incident questions, and SLA-backed delivery of security updates. Hosting providers get the same subscription shaped for a fleet. The software is the same whether or not you hold a subscription.

Builds of the same code the standard packages are built from, produced through a hardened build pipeline with a signed SBOM and build provenance, delivered through the subscriber repository. They differ in how they are built and attested — never in features. Sold as a subscription; pricing is to be announced. The artifacts themselves carry the same Apache License 2.0 as the standard packages; a subscription covers access to the subscriber repository.

Pricing is being finalized. Until it is published, talk to us directly at sales@we-amp.com.

Nothing happens to your deployment. The software is yours under the Apache License 2.0 — it keeps running, keeps optimizing, and you can keep upgrading.

No. The software is free, with no per-server, per-container, or per-request metering of any kind.

Nothing, on that front: the maintained continuation is free too, under the same Apache License 2.0 the original codebase carried. What changed is that it is maintained again — security fixes, a current toolchain, and the optimizer worker — and that the maintenance is funded by support plans and hardened-build subscriptions.

At we-amp.com/licensing/ — the We-Amp terms page.

Apache and nginx ship as GA native modules today, installed from the signed apt/yum repository — see the full distribution matrix. The IIS package ships from the 1.15 packaging channel.

See Getting Started, Troubleshooting, Filter Selection, Cache modes, Admin console, and the archived 1.0 docs.

Yes, on Linux. The WeAmp.PageSpeed.Sidecar NuGet package adds mod_pagespeed to your Kestrel app via middleware, with a bundled nginx + ngx_pagespeed optimizer running on loopback behind it — AddPageSpeed() / UsePageSpeed() wire it in, and a single dotnet add package pulls the bundled native binaries. It is Linux-only (linux-x64, linux-arm64). See the ASP.NET Core sidecar guide. For a cross-platform, in-process integration, see ASP.NET Core Getting Started instead.

Three ways to run it: the native in-process module for Apache and nginx from the signed apt/yum repository (see installation); a Docker / nginx reverse proxy in front of any HTTP origin (Apache, Node.js, Caddy, IIS, your CDN's origin); and the ASP.NET Core middleware NuGet package (WeAmp.PageSpeed.AspNetCore). The same C++ optimization pipeline in all three. The IIS package ships from the 1.15 packaging channel.

In reverse-proxy mode the module runs in front of your origin from the Docker image; the prebuilt nginx module ships inside it — there is no separate bare-metal module to install. Point the reverse proxy at your origin and all optimizations apply automatically.

Yes — as a reverse proxy. Put mod_pagespeed 2.1 in front of your Apache server with the Docker Compose setup, point BACKEND_HOST at your origin, and all optimizations apply automatically. If you want the in-process Apache module instead, it ships from the signed apt/yum repository — see installation.

Yes. The Docker distribution uses separate nginx and worker containers, designed for Kubernetes pod deployments. Configuration is passed as environment variables, making it easy to manage via ConfigMaps and Secrets. A Helm chart is included.

On cache hit, serving is sub-millisecond — just a hash lookup and an mmap pointer. On cache miss, the original content is served immediately while the worker generates optimized variants in the background. There is no synchronous processing in the request path.

The optimizer worker optimizes outside the request path, and its transforms are deliberately conservative: JS minification strips whitespace and comments — no variable renaming — and every image re-encode is checked against a perceptual quality metric. The design falls back to serving your original content when an optimization step fails. No software that rewrites live responses is risk-free, so test on staging before production. You stay in control either way: in the module, pagespeed_disallow skips a URL pattern and pagespeed off disables a location; on the worker, flags like --disable-js turn off a transform type, and a PURGE drops cached variants immediately. See configuration.

CDN-based optimization requires routing your traffic through a third-party proxy. mod_pagespeed runs on your servers — your visitors' content stays on your infrastructure, and the software sends nothing to us. Self-hosted by design; helps your GDPR posture and keeps you in control of caching, configuration, and data.