Apache HTTP Server configuration and tuning

Apache HTTP Server still powers a huge share of production applications: modular, stable and documented like few other pieces of software. Many CMSs, PHP applications and legacy software simply assume Apache and its .htaccess. We configure it for your real workload - not the distro’s default file - so it stays fast, secure and free of constraints.

Overview

We work on Apache at every stage of its life: first installation, tuning an existing server, diagnosing a bottleneck or migrating to a different architecture. The starting point is always the configuration you actually run - virtual hosts, loaded modules, .htaccess rules layered over the years - which we bring back to a clean, versioned, predictable state.

Apache pays for its flexibility with a few well-known pitfalls: mod_php multiplying memory use, the prefork MPM capping concurrency, .htaccess files re-read on every request. These are solvable problems, almost always without switching web server. When Apache genuinely isn’t the most efficient choice for your case, we say so openly: often it just needs Nginx in front as a cache, without throwing away anything that already works.

Typical problems we solve

• The site slows down at traffic peaks and the server runs out of memory → we migrate from mod_php to PHP-FPM with the event MPM and size the limits to your real numbers.
• Layered .htaccess rules that contradict each other → a full audit, cleanup of duplicates and moving rules into the virtual host where it pays off.
• Chained redirects that slow down pages and waste crawl budget → we rewrite the mod_rewrite rules cleanly and test them before release.
• An expired certificate and the site flagged as not secure → we automate issuance and renewal with Let’s Encrypt and keep an eye on expiry dates.
• Pages served without compression or caching → we enable HTTP/2, Brotli and correct caching headers to bring down the TTFB.
• An inherited configuration nobody dares to touch → we rebuild it step by step on staging and document it, so it stops being a black box.
• Constant scans and anomalous requests against sensitive paths → hardening with security headers, request limits and unnecessary modules disabled.

What’s included

• Virtual hosts: multiple sites on one server, name-based or IP-based, with separate logs, permissions and PHP pools so they can’t interfere with each other.
• mod_rewrite and .htaccess: writing, cleaning and tuning redirects, rewrites and SEO-friendly URLs, tested before release.
• From mod_php to PHP-FPM: migration to PHP-FPM with the event MPM to cut memory use and raise concurrency, without breaking existing rules.
• Caching and compression: mod_cache, mod_expires, mod_deflate and Brotli, with headers tuned to bring down the TTFB.
• TLS and certificates: modern ciphers, HSTS, HTTP/2 and automatic renewal via Let’s Encrypt.
• Hardening: security headers, sensitive paths locked down, limits on requests and body size, active modules trimmed to a minimal list.
• Coexistence or migration with Nginx: Apache behind Nginx as a caching layer, or a gradual translation of the rules over to Nginx.

Stack and technologies

We work on Apache 2.4 with the event MPM and PHP-FPM, the combination that today offers the best balance of memory use and concurrency. We enable only the modules that are actually needed - mod_rewrite, mod_ssl, mod_headers, mod_proxy, mod_cache - and wire in Let’s Encrypt for certificates. Where the numbers justify it, we add Nginx or Varnish as a cache in front of Apache, and connect it all to log and performance monitoring. We work mainly on Debian and Ubuntu; on request also AlmaLinux, Rocky Linux, Arch Linux and other distributions. The server can live wherever you prefer: bare-metal, VPS or cloud - we mostly use Google Cloud, with AWS and DigitalOcean as alternatives. Every change lands in versioned, commented configuration, not in on-the-fly tweaks that nobody can explain six months later.

A real-world example

An agency handed us an inherited server running about ten WordPress sites on Apache in prefork mode with mod_php: at traffic peaks the memory would run out, the server would start swapping, and every site slowed down together. We replicated the configuration on staging, migrated to the event MPM with a dedicated PHP-FPM pool per site, cleaned duplicate rewrites out of the .htaccess files and turned on HTTP/2 with Brotli compression. The move to production happened in an agreed window, with no perceptible downtime. Today memory per request is a fraction of what it was, a traffic spike on one site no longer drags down the others, and the agency has a written map of virtual hosts and pools, site by site.

Who it’s for

• PHP applications and CMSs - WordPress, Drupal, Magento - and legacy software that depend on .htaccess.
• Companies and agencies with an inherited Apache server that’s poorly documented or slow under load.
• Anyone weighing a move to PHP-FPM with the event MPM, or introducing Nginx without rewriting everything.
• Teams hosting several sites on the same server who want clean virtual hosts, isolated from each other.

How we work

Before touching anything, we take a snapshot of the current state: loaded modules, virtual hosts, active rules and real memory usage. On that basis we propose the simplest intervention that carries the load, test it on staging and agree the release window with you. The configurations we leave you with are standard, open and documented: no proprietary components, no step that only we understand. You get a single technical point of contact and reports you can read without a dictionary. Standard coverage is Monday to Friday, 10:00-18:00 , with priorities and timeframes described on the response times page; for recurring work, many clients choose hour packages, which never expire. Quotes are always free, with a reply within one business day.