Why Apache for WordPress?

Apache has been the default pairing for WordPress since WordPress existed. A few reasons that pairing has stuck around:

• .htaccess support — WordPress relies heavily on .htaccess files for permalinks, redirects, and security rules. Apache’s per-directory configuration override system makes this trivial; other servers require workarounds.
• Massive ecosystem — Nearly every hosting tutorial, plugin doc, and Stack Overflow answer assumes Apache.
• Module flexibility — mod_rewrite, mod_ssl, mod_security, and dozens of other modules can be toggled on as needed.
• Battle-tested stability — Apache has been running production workloads for three decades.

None of this means Apache is objectively “better” than Nginx or LiteSpeed — it just means it’s an extremely safe, well-supported default, especially for people who want config flexibility over raw throughput.

Prerequisites

Before starting, make sure you have:

• A server running Ubuntu 22.04/24.04 or a similar Debian-based distro (commands below use apt; adjust for CentOS/RHEL with yum/dnf)
• Root or sudo access
• A domain name pointed at your server’s IP (optional for local testing, required for a real launch)
• Basic comfort with the command line
• MySQL or MariaDB available or installable
• PHP 8.1+ (WordPress 6.x recommends PHP 8.0 or newer)

Step 1: Update the Server and Install Apache

sudo apt update && sudo apt upgrade -y
sudo apt install apache2 -y
sudo systemctl enable apache2
sudo systemctl start apache2

Verify it’s running:

sudo systemctl status apache2

Visit http://your-server-ip in a browser — you should see the default Apache welcome page.

Step 2: Install PHP and Required Extensions

WordPress needs PHP along with several extensions for media handling, database access, and caching.

sudo apt install php php-mysql php-curl php-gd php-mbstring \
  php-xml php-xmlrpc php-soap php-intl php-zip libapache2-mod-php -y

Restart Apache to load the PHP module:

sudo systemctl restart apache2

Confirm PHP works by creating a test file:

echo "<?php phpinfo(); ?>" | sudo tee /var/www/html/info.php

Visit http://your-server-ip/info.php, confirm the PHP info page loads, then delete this file — leaving it exposed is a common and easily avoidable security mistake.

sudo rm /var/www/html/info.php

Step 3: Install and Secure MySQL/MariaDB

sudo apt install mysql-server -y
sudo mysql_secure_installation

Answer the prompts to set a root password, remove anonymous users, disable remote root login, and remove the test database.

Create a dedicated database and user for WordPress:

sudo mysql -u root -p

CREATE DATABASE wordpress_db;
CREATE USER 'wp_user'@'localhost' IDENTIFIED BY 'Str0ng-Unique-Password';
GRANT ALL PRIVILEGES ON wordpress_db.* TO 'wp_user'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Never use root as your WordPress database user in production — a compromised WordPress install shouldn’t automatically mean a compromised database server.

Step 4: Download and Configure WordPress

cd /tmp
curl -O https://wordpress.org/latest.tar.gz
tar -xzvf latest.tar.gz
sudo mv wordpress /var/www/yourdomain.com

Set proper ownership and permissions:

sudo chown -R www-data:www-data /var/www/yourdomain.com
sudo find /var/www/yourdomain.com -type d -exec chmod 755 {} \;
sudo find /var/www/yourdomain.com -type f -exec chmod 644 {} \;

Create the wp-config.php file:

cd /var/www/yourdomain.com
sudo cp wp-config-sample.php wp-config.php
sudo nano wp-config.php

Fill in your database details:

define( 'DB_NAME', 'wordpress_db' );
define( 'DB_USER', 'wp_user' );
define( 'DB_PASSWORD', 'Str0ng-Unique-Password' );
define( 'DB_HOST', 'localhost' );

Also generate fresh authentication keys and salts from the WordPress secret key generator and paste them into the same file — don’t leave the placeholder values.

Step 5: Create an Apache Virtual Host

Create a new virtual host file:

sudo nano /etc/apache2/sites-available/yourdomain.com.conf

<VirtualHost *:80>
    ServerName yourdomain.com
    ServerAlias www.yourdomain.com
    DocumentRoot /var/www/yourdomain.com

    <Directory /var/www/yourdomain.com>
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/yourdomain.com-error.log
    CustomLog ${APACHE_LOG_DIR}/yourdomain.com-access.log combined
</VirtualHost>

The AllowOverride All directive is critical — without it, WordPress’s .htaccess rules (which control permalinks) will be silently ignored.

Enable the site and required modules:

sudo a2ensite yourdomain.com.conf
sudo a2enmod rewrite
sudo a2dissite 000-default.conf
sudo systemctl reload apache2

Step 6: Finish the WordPress Web Installer

Visit http://yourdomain.com in your browser. WordPress’s famous five-minute installer will walk you through choosing a site title, admin username, and password. Once complete, log in at /wp-admin.

Step 7: Enable HTTPS with Let’s Encrypt

There’s no good reason to run a WordPress site without HTTPS in 2026. Certbot makes this nearly automatic:

sudo apt install certbot python3-certbot-apache -y
sudo certbot --apache -d yourdomain.com -d www.yourdomain.com

Certbot will edit your virtual host automatically to add a :443 block and redirect HTTP to HTTPS. Confirm auto-renewal is scheduled:

sudo certbot renew --dry-run

Real-World Use Cases

• Small business and portfolio sites — the classic use case, where simplicity and .htaccess-driven plugin compatibility matter more than raw performance.
• Multi-site networks — Apache’s virtual host system scales cleanly to dozens of WordPress installs on one box.
• Agency hosting — agencies managing many client sites appreciate how predictable Apache configuration is across environments.
• Staging environments — quick to spin up, easy to tear down, and every WordPress plugin assumes it exists.

Troubleshooting Common Issues

White screen of death Usually a PHP error or memory limit issue. Check:

sudo tail -f /var/log/apache2/yourdomain.com-error.log

Increase PHP memory in wp-config.php:

define( 'WP_MEMORY_LIMIT', '256M' );

Permalinks return 404 This almost always means mod_rewrite isn’t enabled or AllowOverride isn’t set to All.

sudo a2enmod rewrite
sudo systemctl restart apache2

Then go to Settings > Permalinks in WP admin and click Save to regenerate .htaccess.

“Error establishing a database connection” Check that MySQL is running and the credentials in wp-config.php match exactly:

sudo systemctl status mysql

File upload/permission errors Usually ownership drift after manual file edits:

sudo chown -R www-data:www-data /var/www/yourdomain.com

Security Best Practices

• Keep WordPress core, themes, and plugins updated — most WordPress compromises come from outdated plugins, not Apache itself.
• Disable directory listing: <Directory /var/www/yourdomain.com> Options -Indexes</Directory>
• Block access to wp-config.php explicitly: <Files wp-config.php> Require all denied</Files>
• Limit login attempts with a plugin or mod_security rule set.
• Use strong, unique database credentials — never reuse the root MySQL account.
• Set up a Web Application Firewall (mod_security2) for an extra layer of filtering.
• Regularly back up both the database and wp-content directory.

Performance Optimization

• Enable caching with a plugin like WP Super Cache or W3 Total Cache, paired with Apache’s mod_expires and mod_deflate: <IfModule mod_deflate.c> AddOutputFilterByType DEFLATE text/html text/css application/javascript</IfModule><IfModule mod_expires.c> ExpiresActive On ExpiresByType image/jpeg "access plus 1 month" ExpiresByType text/css "access plus 1 week"</IfModule>
• Switch to PHP-FPM instead of mod_php for better concurrency handling under load.
• Enable OPcache in php.ini to cache compiled PHP bytecode.
• Use a CDN for static assets and images to reduce server load.
• Optimize images before upload — plugins like ShortPixel or Imagify help automate this.
• Tune MaxRequestWorkers in Apache’s MPM config to match your server’s RAM and expected traffic.

Frequently Asked Questions

Do I need mod_rewrite for WordPress? Yes. Pretty permalinks (/blog/my-post/ instead of /?p=123) depend entirely on it.

Can I run multiple WordPress sites on one Apache server? Yes, using separate virtual host files per domain, each pointing to its own document root and database.

Is Apache slower than Nginx for WordPress? Under typical traffic, the difference is negligible, especially when paired with PHP-FPM and caching. Nginx has an edge at very high concurrency, but most sites never reach that threshold.

Should I use mod_php or PHP-FPM? PHP-FPM is generally preferred today for better memory efficiency and concurrent request handling, even when running behind Apache via mod_proxy_fcgi. It also lets you run Apache’s more efficient event MPM, since mod_php requires the older prefork MPM to work safely.

How do I move a WordPress site from staging to production without breaking links? Export the database, then run a search-and-replace on the old domain across the SQL dump before importing it on the new server — a plugin like “Better Search Replace” handles this safely from within WP admin, since a plain text find-and-replace can corrupt PHP-serialized data stored in some WordPress fields.

Do I need a caching plugin if I already configured mod_expires and mod_deflate? They solve different problems. Apache’s mod_expires/mod_deflate control browser-side caching and compression of already-generated pages; a caching plugin (or mod_cache) avoids re-running PHP and database queries on every request by storing a static copy of the rendered page. Using both together gives the best result — fewer server-side computations and smaller, longer-cached responses on the client side.

Summary and Key Takeaways

Setting up Apache for WordPress is a well-worn path for a reason — it’s predictable, flexible, and backed by decades of documentation. The core steps are: install Apache, PHP, and MySQL; configure a virtual host with AllowOverride All; run the WordPress installer; and lock things down with HTTPS and sane file permissions.

Once the base install is running, the real work is ongoing maintenance: keeping software updated, watching logs, and tuning caching as traffic grows. Get those fundamentals right and Apache will happily serve a WordPress site for years without drama.

References

• Apache HTTP Server Documentation
• WordPress Codex: Installing WordPress
• Let’s Encrypt / Certbot Documentation
• Apache mod_rewrite Documentation

The post How to Set Up Apache for Serving WordPress Websites appeared first on Abdul Wahab Junaid.

What Does “Reverse Proxy” Actually Mean Here?

A reverse proxy sits between the client and the backend server, forwarding requests to it and returning the backend’s response to the client as if the proxy had generated it itself. In this setup:

1. A browser requests https://yourdomain.com/app
2. Apache receives the request on port 443
3. Apache forwards it internally to Tomcat on localhost:8080
4. Tomcat processes the request and returns a response
5. Apache passes that response back to the browser

The client never talks to Tomcat directly — it only ever sees Apache.

Why Put Apache in Front of Tomcat?

• SSL termination — Apache’s mod_ssl handles HTTPS cleanly; Tomcat’s SSL configuration is more cumbersome by comparison.
• Static content offloading — Apache serves images, CSS, and JS far more efficiently than Tomcat’s Java-based servlet engine.
• Security isolation — Tomcat never needs to be exposed to the public internet directly; only Apache is.
• Load balancing — Apache can distribute requests across multiple Tomcat instances.
• URL flexibility — you can host multiple applications (some Java, some not) under one domain, routing by path.
• Unified logging and access control — centralize logs, rate limiting, and auth at the Apache layer.

Prerequisites

• A Linux server (Ubuntu 22.04/24.04 used in examples)
• Root/sudo access
• Java installed (OpenJDK 17 or 21 recommended for current Tomcat versions)
• Basic familiarity with XML config files (Tomcat’s server.xml) and Apache’s config syntax

Step 1: Install Java and Tomcat

sudo apt update
sudo apt install openjdk-21-jdk -y
java -version

Download and install Tomcat (adjust the version number as needed):

cd /opt
sudo wget https://dlcdn.apache.org/tomcat/tomcat-10/v10.1.30/bin/apache-tomcat-10.1.30.tar.gz
sudo tar -xzvf apache-tomcat-10.1.30.tar.gz
sudo mv apache-tomcat-10.1.30 tomcat10

Create a dedicated non-root user for Tomcat — never run application servers as root:

sudo useradd -m -U -d /opt/tomcat10 -s /bin/false tomcat
sudo chown -R tomcat:tomcat /opt/tomcat10
sudo chmod +x /opt/tomcat10/bin/*.sh

Step 2: Create a systemd Service for Tomcat

sudo nano /etc/systemd/system/tomcat.service

[Unit]
Description=Apache Tomcat
After=network.target

[Service]
Type=forking
User=tomcat
Group=tomcat

Environment="JAVA_HOME=/usr/lib/jvm/java-21-openjdk-amd64"
Environment="CATALINA_PID=/opt/tomcat10/temp/tomcat.pid"
Environment="CATALINA_HOME=/opt/tomcat10"
Environment="CATALINA_BASE=/opt/tomcat10"

ExecStart=/opt/tomcat10/bin/startup.sh
ExecStop=/opt/tomcat10/bin/shutdown.sh

RestartSec=10
Restart=on-failure

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable tomcat
sudo systemctl start tomcat
sudo systemctl status tomcat

Confirm Tomcat is listening locally:

curl http://localhost:8080

You should see the default Tomcat welcome page HTML returned.

Step 3: Install Apache and Required Proxy Modules

sudo apt install apache2 -y
sudo a2enmod proxy
sudo a2enmod proxy_http
sudo a2enmod proxy_ajp
sudo a2enmod ssl
sudo a2enmod headers
sudo systemctl restart apache2

mod_proxy_http handles standard HTTP proxying; mod_proxy_ajp is an alternative if you prefer the AJP protocol (faster in some setups, but HTTP proxying is simpler and sufficient for most cases).

Step 4: Configure the Virtual Host as a Reverse Proxy

sudo nano /etc/apache2/sites-available/tomcat-proxy.conf

<VirtualHost *:80>
    ServerName yourdomain.com

    ProxyPreserveHost On
    ProxyRequests Off

    ProxyPass "/" "http://localhost:8080/"
    ProxyPassReverse "/" "http://localhost:8080/"

    ErrorLog ${APACHE_LOG_DIR}/tomcat-proxy-error.log
    CustomLog ${APACHE_LOG_DIR}/tomcat-proxy-access.log combined
</VirtualHost>

If you only want to proxy a specific application path rather than the whole domain:

ProxyPass "/myapp" "http://localhost:8080/myapp"
ProxyPassReverse "/myapp" "http://localhost:8080/myapp"

Enable the site:

sudo a2ensite tomcat-proxy.conf
sudo a2dissite 000-default.conf
sudo systemctl reload apache2

Visit http://yourdomain.com — you should now see Tomcat’s response, served transparently through Apache.

Step 5: Add HTTPS Termination

sudo apt install certbot python3-certbot-apache -y
sudo certbot --apache -d yourdomain.com

Certbot adds a <VirtualHost *:443> block automatically. Ensure the proxy directives are duplicated there too, and add headers so Tomcat knows the original request was HTTPS:

<VirtualHost *:443>
    ServerName yourdomain.com

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/yourdomain.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/yourdomain.com/privkey.pem

    ProxyPreserveHost On
    ProxyPass "/" "http://localhost:8080/"
    ProxyPassReverse "/" "http://localhost:8080/"

    RequestHeader set X-Forwarded-Proto "https"
</VirtualHost>

Without X-Forwarded-Proto, Tomcat applications that generate absolute URLs may incorrectly generate http:// links even when served over HTTPS.

Step 6: Configure Tomcat to Trust the Proxy (Optional but Recommended)

In conf/server.xml, add a RemoteIpValve so Tomcat correctly logs the real client IP instead of 127.0.0.1:

<Valve className="org.apache.catalina.valves.RemoteIpValve"
       remoteIpHeader="X-Forwarded-For"
       protocolHeader="X-Forwarded-Proto" />

Restart Tomcat after the change:

sudo systemctl restart tomcat

Real-World Use Cases

• Legacy Java enterprise apps — many internal business applications still run on Tomcat/Java EE stacks and need a modern HTTPS-capable front door.
• Microservices gateways — Apache can route different URL paths to different Tomcat instances or even different backend technologies entirely.
• Migrating monoliths — teams gradually moving off a Tomcat monolith often keep Apache as the stable routing layer while backend services change underneath.
• Multi-tenant Java hosting — hosting providers running many customer WAR files on shared Tomcat instances, isolated behind per-domain Apache vhosts.

Troubleshooting Common Issues

502 Bad Gateway Tomcat isn’t running, or is listening on a different port than configured.

sudo systemctl status tomcat
curl http://localhost:8080

Proxy works but static assets (CSS/JS) are broken Usually caused by relative paths inside the Java app assuming it’s the site root when actually mounted at a subpath. Fix with a ProxyPassReverseCookiePath and confirm the app’s context path matches your proxy path.

Redirect loops after adding HTTPS Almost always missing X-Forwarded-Proto — the backend app redirects to http:// because it doesn’t know the original request was HTTPS.

Session stickiness issues with multiple Tomcat instances If load-balancing across more than one Tomcat node, enable mod_proxy_balancer with session affinity via the route attribute in Tomcat’s jvmRoute, or move sessions to a shared store (Redis, database).

Security Best Practices

• Bind Tomcat to localhost only (or a private network interface) — never expose port 8080 directly to the internet. <Connector port="8080" address="127.0.0.1" protocol="HTTP/1.1" ... />
• Remove Tomcat’s default sample apps (/examples, /docs, /manager if unused) — they’re common attack surface.
• Restrict access to the Tomcat Manager app to specific IPs if it must remain enabled.
• Keep both Apache and Tomcat patched — reverse proxy setups are only as secure as the weakest link.
• Use mod_security on the Apache layer for an additional WAF pass before requests ever reach Java code.
• Set appropriate Header directives to strip or rewrite any internal server info leaking in responses.

Performance Optimization

• Enable connection reuse with mod_proxy‘s keepalive settings: ProxySet keepalive=On
• Serve static content directly from Apache instead of proxying it to Tomcat, using Alias for asset directories.
• Tune Tomcat’s thread pool in server.xml to match expected concurrency: <Connector port="8080" maxThreads="200" minSpareThreads="25" ... />
• Enable Apache’s mod_deflate for gzip compression at the edge, reducing bandwidth for JSON/HTML responses from Tomcat.
• Use a connection pool (like Tomcat’s built-in DBCP) rather than opening new database connections per request.
• Monitor with JMX or a tool like VisualVM to catch memory or thread pool exhaustion before it causes proxy timeouts.

Frequently Asked Questions

Should I use mod_proxy_http or mod_proxy_ajp? HTTP proxying is simpler to configure and debug, and performance differences are minimal for most applications. AJP made more sense historically when HTTP/1.0 overhead was higher; today HTTP proxying is the more common recommendation.

Can Apache load-balance across multiple Tomcat servers? Yes, using mod_proxy_balancer with a <Proxy balancer://cluster> block listing multiple Tomcat worker nodes, for example:

<Proxy "balancer://tomcatcluster">
    BalancerMember "http://192.168.1.10:8080" route=node1
    BalancerMember "http://192.168.1.11:8080" route=node2
    ProxySet lbmethod=byrequests
</Proxy>

ProxyPass "/" "balancer://tomcatcluster/"
ProxyPassReverse "/" "balancer://tomcatcluster/"

Each node’s route value should match the jvmRoute attribute set in that Tomcat instance’s server.xml, which lets Apache maintain session affinity so a given user keeps hitting the same backend node for the life of their session.

What happens if a Tomcat node goes down while load balancing? mod_proxy_balancer marks a failed node as unavailable after a configurable number of failed attempts and routes traffic to the remaining healthy nodes. You can tune this with retry and failonstatus parameters on each BalancerMember, and monitor cluster health live via the built-in balancer-manager handler:

<Location "/balancer-manager">
    SetHandler balancer-manager
    Require ip 127.0.0.1
</Location>

This gives a simple web dashboard showing each node’s status, load, and session count — genuinely useful when debugging uneven traffic distribution.

Do I need to change Tomcat’s default port? Not necessarily — since Tomcat is only reachable via localhost, the default 8080 is fine as long as it’s not exposed externally.

Is this setup suitable for high-traffic production apps? Yes — this is a standard, widely used pattern in enterprise Java deployments, especially when paired with load balancing and proper JVM tuning.

Summary and Key Takeaways

Putting Apache in front of Tomcat gives you the best of both worlds: Apache’s mature HTTPS handling, static file serving, and access control, combined with Tomcat’s solid Java servlet execution. The setup boils down to installing both, enabling mod_proxy and mod_proxy_http, writing a ProxyPass/ProxyPassReverse pair, and layering HTTPS with proper forwarded headers on top.

Once running, the ongoing focus shifts to security isolation (never expose Tomcat directly), performance tuning (thread pools, keepalive, compression), and keeping both layers patched. This is a proven, boring-in-a-good-way architecture that scales from a single small app to enterprise multi-instance deployments.

References

• Apache mod_proxy Documentation
• Apache mod_proxy_http Documentation
• Apache Tomcat Documentation
• Tomcat RemoteIpValve Documentation

The post How to Use Apache as a Reverse Proxy for Tomcat appeared first on Abdul Wahab Junaid.

This guide covers the specific modules, directives, and tuning steps that make Apache genuinely fast at static file delivery.

Why Static File Performance Matters

Every unnecessary byte sent or unnecessary round trip made adds latency. A few compounding effects:

• Page speed directly affects SEO rankings — Core Web Vitals metrics like Largest Contentful Paint are heavily influenced by static asset delivery time.
• Bandwidth costs money — uncompressed assets and missing cache headers mean repeated, avoidable downloads.
• User experience and conversion — studies consistently show bounce rates climb sharply as load time increases.
• Server resource usage — inefficient static file handling ties up worker processes that could be serving dynamic requests instead.

Prerequisites

• A working Apache installation (Ubuntu/Debian examples used below)
• Root or sudo access
• Basic familiarity with Apache’s directory and virtual host configuration
• An existing site with static assets (images, CSS, JS) to optimize

Step 1: Enable the Core Performance Modules

A handful of modules do most of the heavy lifting for static content performance:

sudo a2enmod expires
sudo a2enmod headers
sudo a2enmod deflate
sudo a2enmod brotli
sudo a2enmod cache
sudo a2enmod cache_disk
sudo systemctl restart apache2

• mod_expires — sets Expires and Cache-Control headers so browsers cache assets instead of re-requesting them.
• mod_headers — lets you fine-tune arbitrary response headers.
• mod_deflate — gzip compression for text-based assets.
• mod_brotli — Brotli compression, typically 15-20% smaller than gzip for the same content (available in Apache 2.4.26+).
• mod_cache / mod_cache_disk — server-side caching layer, useful when static files are generated dynamically but rarely change.

Step 2: Configure Browser Caching with mod_expires

Add this inside your virtual host or in a global config file:

<IfModule mod_expires.c>
    ExpiresActive On

    ExpiresByType image/jpeg "access plus 1 year"
    ExpiresByType image/png "access plus 1 year"
    ExpiresByType image/webp "access plus 1 year"
    ExpiresByType image/svg+xml "access plus 1 year"
    ExpiresByType font/woff2 "access plus 1 year"
    ExpiresByType text/css "access plus 1 month"
    ExpiresByType application/javascript "access plus 1 month"
    ExpiresByType text/html "access plus 1 hour"
</IfModule>

Long cache lifetimes for images and fonts make sense because they rarely change; shorter lifetimes for HTML avoid serving stale content after a deploy. If you version your CSS/JS filenames (e.g., app.a1b2c3.js), you can safely cache those for a year too, since a new deploy means a new filename.

Step 3: Add Cache-Control Headers Explicitly

mod_expires sets Expires, but modern browsers prioritize Cache-Control. Combine both:

<IfModule mod_headers.c>
    <FilesMatch "\.(jpg|jpeg|png|gif|webp|svg|woff2?|ttf|eot)$">
        Header set Cache-Control "public, max-age=31536000, immutable"
    </FilesMatch>
    <FilesMatch "\.(css|js)$">
        Header set Cache-Control "public, max-age=2592000"
    </FilesMatch>
</IfModule>

The immutable flag tells supporting browsers not to even revalidate the file before its expiry — a meaningful speedup for repeat visitors.

Step 4: Enable Compression

<IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css
    AddOutputFilterByType DEFLATE application/javascript application/json
    AddOutputFilterByType DEFLATE image/svg+xml
</IfModule>

If mod_brotli is available, prefer it over gzip for supporting clients — Apache will automatically negotiate based on the client’s Accept-Encoding header:

<IfModule mod_brotli.c>
    AddOutputFilterByType BROTLI_COMPRESS text/html text/css application/javascript
</IfModule>

Don’t bother compressing already-compressed formats like JPEG, PNG, WebP, or MP4 — it wastes CPU for negligible or negative size gains.

Step 5: Serve Files with sendfile and Efficient MPM

Apache’s EnableSendfile directive lets the OS kernel handle file transfer directly, bypassing extra userspace copies:

EnableSendfile On

For static-heavy workloads, the event MPM generally outperforms the older prefork MPM because it handles keep-alive connections more efficiently:

sudo a2dismod mpm_prefork
sudo a2enmod mpm_event
sudo systemctl restart apache2

Note: if you’re running mod_php (not PHP-FPM), you’ll need to stick with mpm_prefork, since mod_php isn’t thread-safe. This is another good reason to migrate to PHP-FPM if PHP is in the mix at all.

Step 6: Set Up a Dedicated Static Assets Virtual Host (Optional)

For high-traffic sites, separating static content onto its own subdomain or path can simplify caching and CDN integration:

<VirtualHost *:80>
    ServerName static.yourdomain.com
    DocumentRoot /var/www/static

    <Directory /var/www/static>
        Options -Indexes +FollowSymLinks
        AllowOverride None
        Require all granted
    </Directory>

    <IfModule mod_headers.c>
        Header set Cache-Control "public, max-age=31536000, immutable"
        Header unset ETag
    </IfModule>
    FileETag None
</VirtualHost>

Disabling ETag here is intentional — when serving from multiple servers or after a restart, inode-based ETags can mismatch and cause unnecessary revalidation; a long Cache-Control max-age already covers the caching need.

Step 7: Offload to a CDN (Recommended for Production)

Even a perfectly tuned Apache server benefits from a CDN in front of it for static assets — reduced latency via edge locations, reduced origin load, and built-in DDoS mitigation. Popular options include Cloudflare, AWS CloudFront, and Bunny CDN. Point the CDN at your static virtual host or asset path, and let it handle edge caching using the Cache-Control headers you’ve already configured.

Real-World Use Cases

• E-commerce product images — thousands of product photos benefit enormously from long-lived caching and compression.
• SaaS dashboards — CSS/JS bundles served with immutable caching dramatically speed up repeat logins.
• Documentation sites — often almost entirely static, making this exact tuning the single biggest performance lever available.
• Media/download sites — large file downloads benefit from sendfile and proper Content-Disposition headers.

Troubleshooting Common Issues

Assets aren’t being cached despite the config Check the actual response headers:

curl -I https://yourdomain.com/style.css

Look for Cache-Control and Expires in the output. If missing, confirm the modules are enabled:

apache2ctl -M | grep -E "expires|headers|deflate"

Compression isn’t happening Verify with:

curl -H "Accept-Encoding: gzip" -I https://yourdomain.com/script.js

Look for Content-Encoding: gzip in the response. If absent, check that the MIME type in your AddOutputFilterByType matches what’s actually being served — a mismatched Content-Type header will silently skip compression.

Old cached versions serving after deploy This is a caching success, not a failure — but it means you need cache-busting. Use versioned filenames or query strings (style.css?v=2) so browsers fetch the new file.

High CPU from mod_deflate Compression has a CPU cost. If your server is CPU-bound rather than bandwidth-bound, consider lowering the compression level:

DeflateCompressionLevel 6

(Default is 9; 6 is a common speed/ratio compromise.)

Security Best Practices

• Disable directory listing everywhere static files are served: Options -Indexes
• Prevent execution of scripts in upload/static directories: <Directory /var/www/static/uploads> php_admin_flag engine off RemoveHandler .php .phtml</Directory>
• Set X-Content-Type-Options: nosniff to prevent MIME-sniffing attacks: Header set X-Content-Type-Options "nosniff"
• Restrict access to sensitive static files (backups, config files, .git directories): <FilesMatch "^\.(git|env|htaccess)"> Require all denied</FilesMatch>
• Keep Apache and its modules patched — static file serving is a common target for path traversal attempts.

Performance Optimization Checklist

• Enable mod_expires and mod_headers for long-lived cache headers
• Enable mod_deflate and/or mod_brotli for text-based assets
• Use EnableSendfile On and the event MPM where possible
• Version or hash static filenames for safe long-term caching
• Serve images in modern formats (WebP/AVIF) alongside fallbacks
• Put a CDN in front of static assets for production sites
• Disable ETags in multi-server setups to avoid revalidation mismatches
• Regularly audit uncompressed or uncached assets with browser dev tools or Lighthouse

Frequently Asked Questions

Does Apache’s static file performance really compete with Nginx? For most real-world traffic levels, yes — especially with mod_event, sendfile, and proper caching enabled. Nginx’s edge tends to show up mainly under extremely high concurrency (tens of thousands of simultaneous connections).

Should I compress images with mod_deflate? No. JPEG, PNG, and WebP are already compressed formats; running them through gzip/Brotli wastes CPU for little to no size reduction. Compression should target text-based assets.

What’s the difference between Expires and Cache-Control? Expires is the older HTTP/1.0-era header specifying an absolute date; Cache-Control (HTTP/1.1) is more flexible, using relative max-age values and additional directives like immutable and no-cache. Modern browsers prioritize Cache-Control when both are present.

Is a CDN necessary if Apache is already tuned well? Not strictly necessary, but highly recommended for production sites with geographically distributed visitors — a CDN reduces latency in ways origin-server tuning alone can’t.

Summary and Key Takeaways

Serving static files efficiently with Apache comes down to a short list of well-understood levers: enable long-lived browser caching with mod_expires and mod_headers, compress text assets with mod_deflate/mod_brotli, let the kernel handle file transfer with sendfile, and choose the event MPM when your stack allows it. Layer a CDN on top for production traffic, and you’ve got a static file delivery setup that competes with anything else on the market.

None of this requires exotic configuration — it’s a handful of directives applied consistently, then verified with curl -I and real browser testing. Get these fundamentals in place once, and static asset delivery stops being something you have to think about.

References

• Apache mod_expires Documentation
• Apache mod_deflate Documentation
• Apache mod_headers Documentation
• Apache Performance Tuning Guide
• Apache MPM Documentation

The post How to Serve Static Files Efficiently with Apache appeared first on Abdul Wahab Junaid.

What Is Content Compression, and Why Does It Matter?

Content compression is the process of shrinking the size of files (HTML, CSS, JavaScript, JSON, XML, and more) before Apache sends them to a visitor’s browser. The browser then decompresses the file on arrival and renders it normally. The visitor never notices anything except that the page loaded faster.

Apache handles this through two modules:

• mod_deflate – uses the Gzip compression algorithm, widely supported and the de facto standard for years.
• mod_brotli – uses Google’s Brotli algorithm, which typically compresses better than Gzip but requires a newer Apache build and isn’t available everywhere.

Compression matters because:

• Faster load times – smaller files transfer faster, especially on mobile or slow connections.
• Lower bandwidth costs – less data transferred means lower hosting bills, especially at scale.
• Better SEO – page speed is a ranking factor for search engines, and compression is one of the easiest wins.
• Improved user experience – faster sites reduce bounce rates and improve conversions.

Prerequisites

Before diving in, make sure you have:

• A server running Apache 2.4+ (most modern Linux distributions ship with this)
• Root or sudo access to the server
• Basic familiarity with the command line and editing configuration files
• Apache installed via a package manager (apt, yum/dnf) or compiled from source

Enabling mod_deflate

Step 1: Check if the Module Is Installed

On most distributions, mod_deflate ships with Apache by default. Verify it’s available:

apache2ctl -M | grep deflate

On CentOS/RHEL systems, use:

httpd -M | grep deflate

If you see deflate_module (shared) in the output, it’s already loaded. If not, enable it.

Step 2: Enable the Module

On Debian/Ubuntu:

sudo a2enmod deflate
sudo systemctl restart apache2

On CentOS/RHEL:

The module is usually compiled in by default. If it’s missing from your httpd.conf, add this line:

LoadModule deflate_module modules/mod_deflate.so

Then restart:

sudo systemctl restart httpd

Step 3: Configure Compression Rules

Open your Apache configuration file (commonly /etc/apache2/apache2.conf, /etc/apache2/conf-available/deflate.conf, or a virtual host file) and add the following block:

<IfModule mod_deflate.c>
    # Compress HTML, CSS, JavaScript, Text, XML and fonts
    AddOutputFilterByType DEFLATE application/javascript
    AddOutputFilterByType DEFLATE application/rss+xml
    AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
    AddOutputFilterByType DEFLATE application/x-font
    AddOutputFilterByType DEFLATE application/x-font-opentype
    AddOutputFilterByType DEFLATE application/x-font-otf
    AddOutputFilterByType DEFLATE application/x-font-truetype
    AddOutputFilterByType DEFLATE application/x-font-ttf
    AddOutputFilterByType DEFLATE application/x-javascript
    AddOutputFilterByType DEFLATE application/xhtml+xml
    AddOutputFilterByType DEFLATE application/xml
    AddOutputFilterByType DEFLATE font/opentype
    AddOutputFilterByType DEFLATE font/otf
    AddOutputFilterByType DEFLATE font/ttf
    AddOutputFilterByType DEFLATE image/svg+xml
    AddOutputFilterByType DEFLATE image/x-icon
    AddOutputFilterByType DEFLATE text/css
    AddOutputFilterByType DEFLATE text/html
    AddOutputFilterByType DEFLATE text/javascript
    AddOutputFilterByType DEFLATE text/plain
    AddOutputFilterByType DEFLATE text/xml

    # Don't compress already-compressed formats
    SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|rar|zip|exe|flv|mov|wma|mp3|avi|swf|mp?g|mp4|webm|webp)$ no-gzip

    # Remove the 'Vary' header for proxies that don't handle it correctly
    <IfModule mod_headers.c>
        Header append Vary User-Agent env=!dont-vary
    </IfModule>
</IfModule>

Save the file, test the configuration, and restart Apache:

sudo apachectl configtest
sudo systemctl restart apache2

Setting the Compression Level (Optional Tuning)

You can control how aggressively Apache compresses content using DeflateCompressionLevel, which ranges from 1 (fastest, least compression) to 9 (slowest, best compression):

DeflateCompressionLevel 6

Level 6 is a good balance between CPU usage and compression ratio for most sites. Going to 9 rarely provides meaningful savings but noticeably increases CPU load under heavy traffic.

Enabling Brotli for Even Better Compression

If your Apache build supports Brotli (2.4.26+), it generally compresses 15-25% better than Gzip for text-based assets.

Install the module (Debian/Ubuntu):

sudo apt install brotli
sudo a2enmod brotli
sudo systemctl restart apache2

Configuration:

<IfModule mod_brotli.c>
    AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/css application/javascript application/json
</IfModule>

Many setups configure Apache to serve Brotli to browsers that support it and fall back to Gzip for older browsers, which Apache negotiates automatically based on the Accept-Encoding header sent by the client.

Verifying Compression Is Working

Once configured, confirm compression is actually happening:

Using curl:

curl -H "Accept-Encoding: gzip" -I https://yourdomain.com

Look for Content-Encoding: gzip in the response headers.

Using browser DevTools:

Open Network tab → click a request → check the Response Headers for Content-Encoding: gzip or br.

Online tools:

Sites like GTmetrix or the “Check GZIP Compression” tools will confirm compression and show the percentage of savings.

Real-World Use Cases

• E-commerce sites with large product catalogs and heavy CSS/JS bundles benefit enormously — compression can cut page weight by 60-80% on text assets.
• News and content sites serving large amounts of HTML text see faster time-to-first-byte perception.
• API servers returning JSON payloads can compress responses significantly, which matters for mobile clients on constrained networks.
• Single Page Applications (SPAs) with large JavaScript bundles see some of the biggest gains, since JS often compresses very well.

Common Mistakes to Avoid

1. Compressing already-compressed files – Images (JPEG, PNG), videos, and ZIP files are already compressed. Trying to Gzip them wastes CPU and can even increase file size slightly.
2. Forgetting to restart Apache – Configuration changes don’t take effect until Apache is reloaded or restarted.
3. Setting compression level too high – Level 9 barely improves ratio over level 6 but costs significantly more CPU under load.
4. Not testing with real headers – Some CDNs or proxies strip the Accept-Encoding header, which prevents compression from happening even if the server is configured correctly.
5. Ignoring the Vary header – Missing this header can cause caching proxies to serve compressed content to clients that don’t support it, breaking the page.

Security Considerations

Compression isn’t purely a performance feature — it has a security dimension too.

• BREACH attack – Compression can, in specific scenarios, leak information about secrets embedded in HTTP responses (like CSRF tokens) when combined with attacker-controlled input reflected in the same response. Mitigate this by disabling compression on pages that reflect user input alongside secrets, or by using CSRF tokens that aren’t length-predictable.
• Rate-limit compression on dynamic content if you’re concerned about CPU exhaustion from malicious high-volume requests targeting compressible endpoints.

Performance Optimization Tips

• Combine compression with browser caching (see our companion guide on Apache caching) for maximum effect.
• Pre-compress static assets at build time (e.g., generate .gz versions of CSS/JS during deployment) and serve them directly with mod_deflate‘s static file support, reducing CPU overhead on every request.
• Monitor CPU usage after enabling compression, especially on high-traffic servers with limited cores.
• Use a CDN in front of Apache; most CDNs handle compression at the edge, reducing load on your origin server.

Troubleshooting

Compression not applying:

• Confirm the module is enabled with apache2ctl -M.
• Check that your MIME types match what’s actually being served (text/html vs text/html; charset=UTF-8 can behave differently on older Apache versions).
• Clear any caching layer (CDN, browser cache) that might be serving stale, uncompressed responses.

High CPU usage after enabling:

• Lower the DeflateCompressionLevel.
• Consider pre-compressing static files instead of compressing on every request.

Errors after config changes:

• Always run apachectl configtest before restarting to catch syntax errors early.

Frequently Asked Questions

Does compression affect image files? No, and it shouldn’t. Images should be excluded from compression rules since formats like JPEG and PNG are already compressed.

Is Brotli always better than Gzip? Generally yes for compression ratio, but Gzip has broader compatibility and slightly faster compression speed in some cases. Serving both and letting the browser choose is the safest approach.

Will compression break my site? Properly configured, no. Issues typically arise from double-compression (e.g., compressing at both the CDN and origin) or missing Vary headers.

How much can I expect page size to shrink? Text-based assets (HTML, CSS, JS) typically compress by 60-80%. Overall page weight reduction depends on how much of your page is text versus already-compressed media.

Summary and Key Takeaways

• Content compression reduces file sizes before they’re sent to browsers, cutting load times and bandwidth costs.
• mod_deflate (Gzip) is the standard choice; mod_brotli offers better ratios where supported.
• Configure compression by MIME type, exclude already-compressed formats, and set a sensible compression level (6 is a solid default).
• Always test with apachectl configtest before restarting, and verify with curl or browser DevTools.
• Be aware of the BREACH attack vector when compressing dynamic pages with reflected secrets.
• Pair compression with caching and pre-compression at build time for the best performance gains.

References

• Apache mod_deflate Documentation
• Apache mod_brotli Documentation
• Apache mod_headers Documentation

The post How to Configure Apache for Content Compression appeared first on Abdul Wahab Junaid.

What Is Content Caching, and Why Does It Matter?

Caching stores a copy of content so it can be reused for future requests instead of being regenerated or re-fetched from scratch every time. In Apache, there are two main layers of caching to think about:

1. Client-side (browser) caching – tells the visitor’s browser to store static assets (images, CSS, JS) locally so it doesn’t need to re-download them on every visit.
2. Server-side caching – Apache itself stores generated content (like the output of a dynamic PHP page) in memory or on disk, serving the cached version to subsequent visitors instead of regenerating it each time.

Why it matters:

• Reduced server load – fewer requests hit your application or database layer.
• Faster page loads – cached assets load from local browser storage or Apache’s cache instantly.
• Lower bandwidth usage – repeat visitors don’t re-download unchanged files.
• Better scalability – your server can handle more concurrent visitors with the same hardware.

Prerequisites

• Apache 2.4+ installed with root/sudo access
• mod_expires and mod_headers available (both ship with Apache by default)
• mod_cache, mod_cache_disk, and mod_cache_socache for server-side caching
• Basic understanding of HTTP headers (Cache-Control, Expires, ETag)

Part 1: Browser Caching with mod_expires and mod_headers

Step 1: Enable the Modules

Debian/Ubuntu:

sudo a2enmod expires
sudo a2enmod headers
sudo systemctl restart apache2

CentOS/RHEL:

Ensure these lines exist in httpd.conf:

LoadModule expires_module modules/mod_expires.so
LoadModule headers_module modules/mod_headers.so

Then restart:

sudo systemctl restart httpd

Step 2: Configure Expiration Rules

Add this block to your virtual host file or .htaccess:

<IfModule mod_expires.c>
    ExpiresActive On

    # Images
    ExpiresByType image/jpg "access plus 1 year"
    ExpiresByType image/jpeg "access plus 1 year"
    ExpiresByType image/gif "access plus 1 year"
    ExpiresByType image/png "access plus 1 year"
    ExpiresByType image/webp "access plus 1 year"
    ExpiresByType image/svg+xml "access plus 1 year"
    ExpiresByType image/x-icon "access plus 1 year"

    # Video
    ExpiresByType video/mp4 "access plus 1 year"

    # CSS, JavaScript
    ExpiresByType text/css "access plus 1 month"
    ExpiresByType application/javascript "access plus 1 month"
    ExpiresByType text/javascript "access plus 1 month"

    # Fonts
    ExpiresByType font/woff2 "access plus 1 year"
    ExpiresByType font/woff "access plus 1 year"
    ExpiresByType application/vnd.ms-fontobject "access plus 1 year"

    # HTML - short cache since content changes often
    ExpiresByType text/html "access plus 0 seconds"

    # Default
    ExpiresDefault "access plus 2 days"
</IfModule>

Step 3: Add Cache-Control Headers

Expires headers are somewhat legacy; modern setups pair them with Cache-Control for finer-grained control:

<IfModule mod_headers.c>
    <FilesMatch "\.(ico|jpg|jpeg|png|gif|webp|svg|css|js|woff|woff2)$">
        Header set Cache-Control "max-age=31536000, public, immutable"
    </FilesMatch>

    <FilesMatch "\.(html|htm)$">
        Header set Cache-Control "max-age=0, no-cache, must-revalidate"
    </FilesMatch>
</IfModule>

The immutable directive tells modern browsers not to even revalidate the file until it expires — useful for versioned static assets (e.g., style.abc123.css).

Part 2: Server-Side Caching with mod_cache

Server-side caching is especially useful for dynamic content (PHP, proxied backends) that’s expensive to regenerate on every request.

Step 1: Enable Required Modules

sudo a2enmod cache
sudo a2enmod cache_disk
sudo systemctl restart apache2

Step 2: Configure Disk Caching

Add this to your Apache config:

<IfModule mod_cache.c>
    <IfModule mod_cache_disk.c>
        CacheRoot /var/cache/apache2/mod_cache_disk
        CacheEnable disk /
        CacheDirLevels 2
        CacheDirLength 1
        CacheMaxFileSize 5000000
        CacheMinFileSize 1
        CacheIgnoreHeaders Set-Cookie
        CacheDefaultExpire 3600
        CacheMaxExpire 86400
        CacheLastModifiedFactor 0.5
    </IfModule>
</IfModule>

Create the cache directory and set proper permissions:

sudo mkdir -p /var/cache/apache2/mod_cache_disk
sudo chown -R www-data:www-data /var/cache/apache2/mod_cache_disk

On CentOS/RHEL, the Apache user is typically apache instead of www-data.

Step 3: Restart and Test

sudo apachectl configtest
sudo systemctl restart apache2

Verify caching is active by checking response headers:

curl -I https://yourdomain.com

Look for an X-Cache or Age header, depending on your configuration, indicating whether the response came from cache.

Using mod_cache_socache for Shared Memory Caching

For high-traffic sites, an in-memory cache is faster than disk. mod_cache_socache works with a shared object cache provider like mod_socache_shmcb:

sudo a2enmod cache_socache
sudo a2enmod socache_shmcb

<IfModule mod_cache_socache.c>
    CacheSocache shmcb
    CacheSocacheMaxSize 102400
    CacheEnable socache /
</IfModule>

Memory caches are faster but limited by available RAM and cleared on restart, so they’re best combined with disk caching as a fallback.

Real-World Use Cases

• WordPress and CMS-driven sites – caching rendered HTML pages avoids expensive PHP/database calls on every request.
• Reverse proxy setups – Apache configured as a reverse proxy in front of application servers (Node.js, Python) benefits enormously from caching proxied responses.
• Static asset-heavy sites – portfolios, marketing sites, and documentation sites with lots of images and fonts see immediate load-time improvements.
• API gateways – caching read-heavy, infrequently changing API responses reduces backend load significantly.

Common Mistakes to Avoid

1. Caching sensitive or personalized content – Never cache pages containing user-specific data (account pages, checkout) without proper Vary and Cache-Control: private headers.
2. Setting cache lifetimes too long on HTML – HTML often changes; caching it for a year like static assets leads to stale content.
3. Forgetting cache busting for updated assets – Use versioned filenames (e.g., app.v2.js) or query strings so browsers fetch new versions after deployment.
4. Not excluding cookies from cached responses – Failing to set CacheIgnoreHeaders Set-Cookie can cause one user’s session cookie to be served to another.
5. Ignoring cache invalidation – Have a plan (cache-clear command, TTL, or deployment hook) for purging stale cached content.

Security Best Practices

• Never cache authenticated or personalized pages without explicit private cache directives.
• Set CacheIgnoreHeaders Set-Cookie to avoid leaking session data between users.
• Restrict write access to the cache directory to the Apache user only.
• If using a CDN alongside Apache caching, ensure cache purge mechanisms are coordinated to avoid serving outdated or sensitive content.

Performance Optimization Tips

• Combine caching with compression (see our companion Apache compression guide) — compress once, cache the compressed output.
• Use long max-age values with immutable, versioned filenames for static assets.
• Monitor cache hit ratios; a low hit ratio may mean your cache rules or TTLs need adjustment.
• Consider a dedicated reverse proxy cache (like Varnish) in front of Apache for very high-traffic sites, using Apache’s caching as a secondary layer.

Troubleshooting

Cache not being used:

• Confirm mod_cache and mod_cache_disk are enabled with apache2ctl -M.
• Check that CacheEnable matches the correct URL path.
• Ensure the cache directory has correct write permissions.

Stale content being served:

• Lower CacheMaxExpire or manually clear the cache directory: sudo rm -rf /var/cache/apache2/mod_cache_disk/*.
• Verify your application isn’t sending conflicting cache headers that override Apache’s rules.

Disk filling up:

• Set CacheMaxFileSize to a reasonable limit and monitor disk usage; old cache entries are cleaned up automatically but a CacheQuickHandler misconfiguration can sometimes bypass expiry logic.

Frequently Asked Questions

What’s the difference between Expires and Cache-Control? Expires sets an absolute date/time; Cache-Control uses relative directives like max-age and offers more granular control (public/private, no-cache, immutable). Modern setups favor Cache-Control, with Expires as a fallback for older clients.

Should I cache HTML pages? Static HTML can be cached briefly; dynamically generated HTML (like a CMS homepage) can be cached server-side with mod_cache but usually with a short TTL to balance freshness and performance.

Does caching work with HTTPS? Yes, caching operates independently of TLS termination and works the same way over HTTPS.

How do I clear the Apache cache? For disk caching, remove the contents of the CacheRoot directory. For browser caching, that’s controlled by the client, though cache-busting filenames force a refresh.

Summary and Key Takeaways

• Apache caching operates on two levels: browser caching (mod_expires, mod_headers) and server-side caching (mod_cache).
• Set long cache lifetimes for static, versioned assets and short or no caching for dynamic HTML.
• Use Cache-Control alongside Expires for the best browser compatibility.
• Server-side caching with mod_cache_disk or mod_cache_socache reduces load on backend applications significantly.
• Always exclude cookies and personalized content from cached responses.
• Monitor cache hit rates and have a clear invalidation strategy for deployments.

References

• Apache mod_cache Documentation
• Apache mod_expires Documentation
• Apache mod_headers Documentation
• Apache Caching Guide

The post How to Set Up Apache for Content Caching appeared first on Abdul Wahab Junaid.

What Is Server-Side Scripting?

Server-side scripting means running code on the web server before the response is sent to the browser, rather than in the visitor’s browser (which is client-side scripting, like JavaScript running in Chrome). Common server-side languages include PHP, Python, Perl, and Ruby.

Apache doesn’t execute these languages natively. Instead, it relies on modules or protocols to hand off requests to an interpreter:

• mod_php – runs PHP directly inside the Apache process (legacy but still common)
• PHP-FPM via mod_proxy_fcgi – runs PHP as a separate FastCGI process pool (modern, recommended)
• mod_wsgi – runs Python web applications (Django, Flask)
• mod_perl – embeds a Perl interpreter in Apache
• mod_cgi / mod_cgid – runs any executable script as a CGI program, language-agnostic but slower

This guide covers the general mechanism and setup for CGI and FastCGI, since those are the foundation most language-specific guides (PHP, Python, Ruby) build on. For deep dives into specific stacks, see our companion articles on PHP and Python with Apache.

Prerequisites

• Apache 2.4+ with root/sudo access
• A Linux server (Ubuntu/Debian or CentOS/RHEL examples below)
• Basic familiarity with file permissions and the command line
• The scripting language/interpreter you intend to use already installed (e.g., php, python3, perl)

Enabling CGI Scripting (The Foundation)

CGI (Common Gateway Interface) is the original method for server-side scripting and still useful for simple scripts or legacy systems.

Step 1: Enable mod_cgi

Debian/Ubuntu (using the threaded mpm_event, use mod_cgid instead):

sudo a2enmod cgid
sudo systemctl restart apache2

CentOS/RHEL:

LoadModule cgid_module modules/mod_cgid.so

Step 2: Designate a CGI Directory

Edit your virtual host configuration:

<VirtualHost *:80>
    ServerName example.com
    DocumentRoot /var/www/example.com/public_html

    ScriptAlias /cgi-bin/ /var/www/example.com/cgi-bin/

    <Directory "/var/www/example.com/cgi-bin">
        AllowOverride None
        Options +ExecCGI
        Require all granted
        AddHandler cgi-script .cgi .pl .py
    </Directory>
</VirtualHost>

Step 3: Write a Test Script

sudo mkdir -p /var/www/example.com/cgi-bin
sudo nano /var/www/example.com/cgi-bin/test.cgi

#!/usr/bin/perl
print "Content-type: text/html\n\n";
print "<html><body><h1>CGI is working!</h1></body></html>";

Make it executable:

sudo chmod +x /var/www/example.com/cgi-bin/test.cgi

Restart Apache and visit http://example.com/cgi-bin/test.cgi to confirm it works.

Enabling FastCGI (Modern, Recommended Approach)

FastCGI keeps interpreter processes running persistently instead of starting a new process per request, which is dramatically faster under load. This is the backbone of modern PHP-FPM and many Python deployments.

Step 1: Enable Proxy and FastCGI Modules

sudo a2enmod proxy
sudo a2enmod proxy_fcgi
sudo a2enmod setenvif
sudo systemctl restart apache2

Step 2: Configure a FastCGI Handler

Example configuration pointing to a FastCGI process listening on a Unix socket (this pattern applies whether the backend is PHP-FPM, a Python WSGI server behind FastCGI, or similar):

<FilesMatch "\.php$">
    SetHandler "proxy:unix:/run/php/php8.3-fpm.sock|fcgi://localhost/"
</FilesMatch>

This exact pattern is explored in depth in our PHP-specific guide, since PHP-FPM is the most common real-world use of FastCGI with Apache.

Real-World Use Cases

• Contact forms and dynamic content – processing form submissions, sending emails, validating input.
• Content management systems – WordPress, Drupal, and Joomla all rely on server-side PHP execution.
• Web applications – Django/Flask (Python), Rails (Ruby), and similar frameworks require server-side execution to render pages and handle business logic.
• APIs and microservices – server-side scripts process requests, query databases, and return JSON responses.
• Legacy CGI scripts – some older systems (bioinformatics tools, internal admin scripts) still rely on classic CGI.

Common Mistakes to Avoid

1. Forgetting +ExecCGI or the correct SetHandler – Without explicitly allowing script execution, Apache will serve the raw script source code instead of running it, which is both a functionality bug and a security risk.
2. Incorrect file permissions – Scripts need execute permissions (chmod +x) for CGI; FastCGI sockets need correct ownership matching the Apache/FPM user.
3. Mixing mod_php and PHP-FPM – Running both simultaneously can cause confusing behavior; pick one approach per site.
4. Not restarting after enabling modules – Module changes require a full restart, not just a reload, in some cases.
5. Leaving default/test scripts accessible in production – Test CGI scripts left in place can become an attack surface.

Security Best Practices

• Never enable ExecCGI or scripting handlers on directories that accept file uploads. If an attacker can upload a script and it lands in an executable-enabled directory, they can achieve remote code execution.
• Restrict scripting to specific, well-defined directories rather than enabling it site-wide with Options +ExecCGI in the DocumentRoot.
• Keep interpreters updated – PHP, Python, and Perl all receive regular security patches; outdated interpreters are a common attack vector.
• Run scripts with least privilege – use a dedicated, non-privileged system user for the web server and script execution, never root.
• Validate and sanitize all input in your scripts themselves; Apache’s job is just to execute the code, not to secure your application logic.
• Disable directory listing (Options -Indexes) so visitors can’t browse your cgi-bin or script directories directly.

Performance Optimization Tips

• Prefer FastCGI/FPM over classic CGI wherever possible; process-per-request CGI is significantly slower under concurrent load.
• Tune process pool sizes (e.g., PHP-FPM’s pm.max_children) to match your server’s CPU and memory resources.
• Use opcode/bytecode caching where available (like PHP’s OPcache) to avoid recompiling scripts on every request.
• Combine with caching (see our Apache caching guide) for pages that don’t need to be regenerated on every single request.

Troubleshooting

“Internal Server Error” (500):

• Check Apache’s error log: sudo tail -f /var/log/apache2/error.log
• Common causes: incorrect shebang line in the script, missing execute permission, or a syntax error in the script itself.

Script downloads instead of executing:

• The handler isn’t correctly configured. Double-check AddHandler or SetHandler directives and that the relevant module is enabled.

“Premature end of script headers”:

• The script didn’t output a valid Content-type header before any content. Every CGI script must print headers first, followed by a blank line, then content.

FastCGI socket connection errors:

• Verify the backend process (like PHP-FPM) is running: sudo systemctl status php8.3-fpm
• Confirm the socket path in Apache’s config matches the actual socket file location and permissions.

Frequently Asked Questions

What’s the difference between CGI and FastCGI? CGI spawns a new process for every request, which is simple but slow. FastCGI keeps a pool of persistent processes running, dramatically reducing overhead per request.

Do I need mod_cgi if I’m using PHP-FPM? No. PHP-FPM uses mod_proxy_fcgi, not classic CGI. mod_cgi is only needed for traditional CGI scripts (Perl, Python scripts written as standalone CGI programs, shell scripts, etc.).

Is server-side scripting a security risk by itself? Not inherently, but misconfigured scripting handlers (enabling execution in upload directories, running as root, outdated interpreters) are among the most common causes of server compromise.

Can I run multiple languages on the same Apache server? Yes. It’s common to run PHP-FPM for one site and a Python WSGI app (via mod_wsgi or a reverse-proxied app server) for another, all behind the same Apache instance using separate virtual hosts.

Summary and Key Takeaways

• Server-side scripting lets Apache execute code (PHP, Python, Perl, Ruby, etc.) to generate dynamic content before sending a response.
• Classic CGI (mod_cgi/mod_cgid) is simple but slow; FastCGI (mod_proxy_fcgi) is the modern, performant standard.
• Always scope scripting permissions to specific directories, never site-wide, and never in upload directories.
• Keep interpreters patched and run them under a least-privilege user.
• Check Apache’s error log first when scripts fail — most issues (permissions, missing headers, syntax errors) show up there immediately.

References

• Apache mod_cgi Documentation
• Apache mod_proxy_fcgi Documentation
• Apache Dynamic Content with CGI Guide

The post How to Enable Server-Side Scripting in Apache appeared first on Abdul Wahab Junaid.

Understanding How Apache and Rails Work Together

Unlike PHP, Rails applications don’t run inside Apache. A Rails app is a standalone Ruby process (or set of processes) that runs independently, typically using an application server like Puma (the default since Rails 5), Unicorn, or Passenger.

Apache’s role is to sit in front of that Rails process as a reverse proxy, forwarding incoming HTTP requests to the Rails app server and returning its responses to the client. Apache also handles tasks Rails shouldn’t have to worry about directly: SSL termination, serving static assets efficiently, load balancing across multiple app instances, and request logging.

There are two common approaches:

1. mod_proxy + Puma/Unicorn – Apache proxies requests to a Ruby app server running as a separate process. This is the modern, most common approach.
2. Passenger (mod_passenger) – An Apache module that manages the Rails application lifecycle directly, so you don’t need to manually run and monitor a separate app server process.

This guide covers both.

Prerequisites

• A Linux server with Apache 2.4+ installed
• Ruby (2.7+, ideally 3.x) and Rails installed, along with a working Rails application
• Root or sudo access
• Basic familiarity with the command line and Rails’ directory structure
• Bundler installed (gem install bundler)

Approach 1: Apache as a Reverse Proxy to Puma

Step 1: Install Required Apache Modules

sudo a2enmod proxy
sudo a2enmod proxy_http
sudo a2enmod headers
sudo systemctl restart apache2

Step 2: Prepare Your Rails App

Inside your Rails app directory, make sure Puma is configured. Rails ships with a config/puma.rb file by default:

# config/puma.rb
max_threads_count = ENV.fetch("RAILS_MAX_THREADS") { 5 }
min_threads_count = ENV.fetch("RAILS_MIN_THREADS") { max_threads_count }
threads min_threads_count, max_threads_count

port ENV.fetch("PORT") { 3000 }

environment ENV.fetch("RAILS_ENV") { "production" }

pidfile ENV.fetch("PIDFILE") { "tmp/pids/server.pid" }

Precompile assets and set up the production environment:

RAILS_ENV=production bin/rails assets:precompile
RAILS_ENV=production bin/rails db:migrate

Start Puma (in production, you’d typically run this under a process manager like systemd):

RAILS_ENV=production bundle exec puma -C config/puma.rb

Step 3: Create a systemd Service for Puma

Rather than running Puma manually, create a persistent service:

sudo nano /etc/systemd/system/puma.service

[Unit]
Description=Puma HTTP Server for MyRailsApp
After=network.target

[Service]
Type=simple
User=deploy
WorkingDirectory=/var/www/myrailsapp
Environment=RAILS_ENV=production
ExecStart=/usr/local/rvm/bin/rvm-exec 3.2.0 bundle exec puma -C config/puma.rb
Restart=always

[Install]
WantedBy=multi-user.target

Enable and start it:

sudo systemctl daemon-reload
sudo systemctl enable puma
sudo systemctl start puma

Step 4: Configure Apache as a Reverse Proxy

Create a virtual host:

<VirtualHost *:80>
    ServerName myrailsapp.com

    ProxyPreserveHost On
    ProxyPass / http://127.0.0.1:3000/
    ProxyPassReverse / http://127.0.0.1:3000/

    # Serve static assets directly from Apache for better performance
    Alias /assets /var/www/myrailsapp/public/assets
    <Directory /var/www/myrailsapp/public/assets>
        Require all granted
        Header set Cache-Control "public, max-age=31536000, immutable"
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/myrailsapp_error.log
    CustomLog ${APACHE_LOG_DIR}/myrailsapp_access.log combined
</VirtualHost>

Enable the site and restart Apache:

sudo a2ensite myrailsapp.conf
sudo apachectl configtest
sudo systemctl restart apache2

Approach 2: Using Passenger

Passenger integrates more tightly with Apache, managing the Rails process lifecycle for you, which simplifies deployment for many teams.

Step 1: Install Passenger

sudo apt install -y dirmngr gnupg apt-transport-https ca-certificates curl
curl https://oss-binaries.phusionpassenger.com/auto-software-signing-gpg-key.txt | sudo gpg --dearmor -o /usr/share/keyrings/phusion.gpg
sudo sh -c "echo 'deb [signed-by=/usr/share/keyrings/phusion.gpg] https://oss-binaries.phusionpassenger.com/apt/passenger jammy main' > /etc/apt/sources.list.d/passenger.list"
sudo apt update
sudo apt install -y libapache2-mod-passenger

Step 2: Enable the Module

sudo a2enmod passenger
sudo systemctl restart apache2

Verify installation:

sudo /usr/bin/passenger-config validate-install

Step 3: Configure the Virtual Host

<VirtualHost *:80>
    ServerName myrailsapp.com
    DocumentRoot /var/www/myrailsapp/public

    <Directory /var/www/myrailsapp/public>
        Allow from all
        Options -MultiViews
        Require all granted
    </Directory>

    PassengerRuby /usr/local/rvm/gems/ruby-3.2.0/wrappers/ruby
</VirtualHost>

With Passenger, there’s no need to manually manage a Puma process — Passenger starts and monitors Rails automatically based on the DocumentRoot pointing to public/.

Enabling SSL/HTTPS

Regardless of which approach you use, secure your Rails app with SSL using Let’s Encrypt:

sudo apt install certbot python3-certbot-apache
sudo certbot --apache -d myrailsapp.com

Certbot automatically updates your virtual host configuration to redirect HTTP to HTTPS and manages certificate renewal.

Real-World Use Cases

• SaaS applications – Rails’ convention-over-configuration approach makes it popular for building subscription-based web apps, with Apache handling SSL and load balancing in front.
• E-commerce platforms – Rails powers platforms like Shopify’s early architecture; Apache/Nginx reverse proxies are standard in front of such apps.
• Internal business tools – Rails is a common choice for rapid internal tool development, often deployed behind Apache in corporate environments already standardized on Apache.
• API backends – Rails in API-only mode paired with Apache as a proxy and rate-limiter for mobile or SPA frontends.

Common Mistakes to Avoid

1. Forgetting to precompile assets – Running Rails in production without assets:precompile results in broken CSS/JS.
2. Not setting RAILS_ENV=production – Running in development mode in production is a serious performance and security issue (verbose error pages leak information).
3. Proxying static assets through Rails – Let Apache serve /public/assets directly rather than routing every asset request through the Ruby process.
4. Missing ProxyPreserveHost – Without it, Rails may generate incorrect URLs (using the internal proxy address instead of the public domain).
5. Running Puma as root – Always run application processes under a dedicated, non-privileged user.

Security Best Practices

• Always run Rails in production mode with config.force_ssl = true in config/environments/production.rb.
• Keep SECRET_KEY_BASE and other credentials out of version control; use Rails encrypted credentials or environment variables.
• Set appropriate Content-Security-Policy and other security headers via mod_headers in Apache or Rails middleware.
• Regularly run bundle audit to check for vulnerable gems.
• Restrict direct access to port 3000 (or whatever Puma listens on) from outside the server — only Apache should be able to reach it, typically via binding Puma to 127.0.0.1.

Performance Optimization Tips

• Serve static assets and uploaded files directly through Apache rather than proxying them through Rails.
• Use a CDN for assets in high-traffic production apps.
• Tune Puma’s worker/thread counts based on available CPU cores (WEB_CONCURRENCY and RAILS_MAX_THREADS).
• Enable HTTP/2 in Apache for faster asset delivery on the client side.
• Combine with the caching techniques from our Apache caching guide for cacheable pages.

Troubleshooting

502 Bad Gateway:

• Puma isn’t running or isn’t listening on the expected port. Check with sudo systemctl status puma and curl http://127.0.0.1:3000.

Assets not loading (404s for CSS/JS):

• Confirm assets:precompile ran successfully and the Alias path in your Apache config matches the actual public/assets directory.

“We’re sorry, but something went wrong” generic error page:

• Check log/production.log in your Rails app directory for the actual stack trace.

Passenger not starting the app:

• Run passenger-status to see running application instances, and check Apache’s error log for Passenger-specific startup errors.

Frequently Asked Questions

Should I use Puma or Passenger? Puma with a manual reverse proxy gives more control and is the more common modern pattern, especially in containerized/cloud deployments. Passenger is simpler to set up and manages the process lifecycle for you, which some teams prefer for traditional VPS deployments.

Can I run multiple Rails apps on one Apache server? Yes, using separate virtual hosts, each proxying to a different Puma instance on a different port (or Passenger handling each independently based on DocumentRoot).

Is Nginx better than Apache for Rails? Nginx is more commonly seen in Rails tutorials, but Apache works equally well as a reverse proxy. The choice often comes down to existing infrastructure and team familiarity rather than a hard technical requirement.

Do I need Apache at all, or can Puma serve requests directly? Puma can serve requests directly, but putting Apache in front provides SSL termination, static asset serving, load balancing, and additional security controls that are impractical to replicate in Puma alone.

Summary and Key Takeaways

• Rails doesn’t run inside Apache; it runs as a separate process (via Puma, Unicorn, or Passenger), with Apache acting as a reverse proxy.
• mod_proxy and mod_proxy_http are the key modules for proxying to Puma; Passenger offers a more integrated alternative.
• Always run Rails in production mode, precompile assets, and serve static files directly through Apache.
• Secure the deployment with SSL (Certbot/Let’s Encrypt), proper environment variables, and restricted access to the internal app server port.
• Tune Puma’s thread/worker settings to match your server resources for the best performance.

References

• Apache mod_proxy Documentation
• Apache mod_proxy_http Documentation
• Ruby on Rails Guides: Configuring Rails Applications
• Phusion Passenger Documentation

The post How to Use Apache with Ruby on Rails appeared first on Abdul Wahab Junaid.

Understanding How Python Works with Apache

Python web frameworks like Flask and Django follow the WSGI (Web Server Gateway Interface) specification, a standard that defines how a web server communicates with a Python application. Apache doesn’t understand WSGI natively, so it needs a bridge: mod_wsgi.

mod_wsgi embeds a Python interpreter inside Apache (or runs it in separate daemon processes) and handles translating HTTP requests into calls your Python application understands, then converts the application’s response back into an HTTP response.

There are two operating modes:

• Embedded mode – Python runs inside Apache’s own worker processes. Simpler but less isolated.
• Daemon mode – Python runs in separate, dedicated processes managed by mod_wsgi. Recommended for production because it isolates your app from Apache’s process lifecycle and allows independent restarts.

Prerequisites

• A Linux server with Apache 2.4+ installed
• Root or sudo access
• Python 3.8+ installed (python3 --version)
• pip and venv available
• A Python web application (Flask or Django example used below)

Step 1: Install Python and Development Tools

Debian/Ubuntu:

sudo apt update
sudo apt install python3 python3-pip python3-venv python3-dev apache2 apache2-dev libapache2-mod-wsgi-py3

CentOS/RHEL:

sudo dnf install python3 python3-pip python3-devel httpd httpd-devel
sudo dnf install python3-mod_wsgi

Step 2: Enable mod_wsgi

Debian/Ubuntu:

sudo a2enmod wsgi
sudo systemctl restart apache2

Verify it loaded:

apache2ctl -M | grep wsgi

CentOS/RHEL:

Ensure this line exists in your Apache configuration:

LoadModule wsgi_module modules/mod_wsgi.so

Then restart:

sudo systemctl restart httpd

Step 3: Set Up a Python Virtual Environment

Isolating dependencies in a virtual environment is essential for production stability:

sudo mkdir -p /var/www/myflaskapp
cd /var/www/myflaskapp
python3 -m venv venv
source venv/bin/activate
pip install flask

Step 4: Create a Simple Flask Application

nano /var/www/myflaskapp/app.py

from flask import Flask

app = Flask(__name__)

@app.route("/")
def home():
    return "Hello from Flask running on Apache with mod_wsgi!"

if __name__ == "__main__":
    app.run()

Step 5: Create the WSGI Entry Point

nano /var/www/myflaskapp/myflaskapp.wsgi

#!/usr/bin/python3
import sys
import logging

logging.basicConfig(stream=sys.stderr)

sys.path.insert(0, "/var/www/myflaskapp/")

from app import app as application

The variable must be named application — this is the convention mod_wsgi looks for.

Step 6: Configure the Apache Virtual Host

<VirtualHost *:80>
    ServerName myflaskapp.com

    WSGIDaemonProcess myflaskapp python-home=/var/www/myflaskapp/venv python-path=/var/www/myflaskapp
    WSGIProcessGroup myflaskapp
    WSGIScriptAlias / /var/www/myflaskapp/myflaskapp.wsgi

    <Directory /var/www/myflaskapp>
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/myflaskapp_error.log
    CustomLog ${APACHE_LOG_DIR}/myflaskapp_access.log combined
</VirtualHost>

WSGIDaemonProcess with python-home pointing to the virtual environment ensures Apache uses your isolated Python packages rather than the system-wide installation.

Enable the site and restart:

sudo a2ensite myflaskapp.conf
sudo apachectl configtest
sudo systemctl restart apache2

Visit http://myflaskapp.com — you should see the Flask response.

Configuring Django with Apache

Django follows a similar pattern but with a slightly different WSGI entry point structure, since Django generates wsgi.py automatically.

Step 1: Set Up the Django Project

cd /var/www
python3 -m venv django_env
source django_env/bin/activate
pip install django
django-admin startproject myproject

Step 2: Configure the Apache Virtual Host

<VirtualHost *:80>
    ServerName mydjangoapp.com

    WSGIDaemonProcess myproject python-home=/var/www/django_env python-path=/var/www/myproject
    WSGIProcessGroup myproject
    WSGIScriptAlias / /var/www/myproject/myproject/wsgi.py

    <Directory /var/www/myproject/myproject>
        <Files wsgi.py>
            Require all granted
        </Files>
    </Directory>

    Alias /static/ /var/www/myproject/static/
    <Directory /var/www/myproject/static>
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/mydjangoapp_error.log
    CustomLog ${APACHE_LOG_DIR}/mydjangoapp_access.log combined
</VirtualHost>

Don’t forget to run collectstatic before going live:

python manage.py collectstatic

Real-World Use Cases

• Data-driven web dashboards – Python’s data science ecosystem (pandas, matplotlib) pairs naturally with Flask/Django apps serving visualizations.
• Internal admin tools – Django’s built-in admin panel is a common choice for internal business applications deployed behind Apache.
• REST APIs – Flask or Django REST Framework backends serving mobile or JavaScript frontend applications.
• Machine learning model serving – Lightweight Flask apps wrapping ML models for inference, deployed behind Apache for SSL and load balancing.

Common Mistakes to Avoid

1. Forgetting python-home in WSGIDaemonProcess – Without it, Apache uses the system Python, missing your virtual environment’s packages, leading to ModuleNotFoundError.
2. Naming the WSGI callable incorrectly – It must be named application, not app, in the .wsgi file (even though your Flask variable can be named app inside app.py, the imported alias in the wsgi file must be application).
3. Running the dev server in production – app.run() or Django’s runserver are not production-grade; always use mod_wsgi (or Gunicorn behind a proxy) instead.
4. Mixing Python 2 and Python 3 mod_wsgi packages – Ensure you install libapache2-mod-wsgi-py3 specifically, not the Python 2 version.
5. Incorrect file permissions – The Apache user needs read access to your application directory and virtual environment.

Security Best Practices

• Set DEBUG = False in Django’s settings for production; leaving debug mode on exposes sensitive stack traces and environment details.
• Store secrets (SECRET_KEY, database credentials) in environment variables, not hardcoded in source files.
• Restrict ALLOWED_HOSTS in Django to your actual domain(s).
• Run WSGIDaemonProcess under a dedicated, non-privileged user rather than the default Apache user where isolation matters.
• Keep Python, Flask/Django, and all dependencies updated; use pip list --outdated and tools like pip-audit regularly.

Performance Optimization Tips

• Use daemon mode (not embedded mode) for better process isolation and easier scaling.
• Tune processes and threads in WSGIDaemonProcess based on your workload:

WSGIDaemonProcess myflaskapp python-home=/var/www/myflaskapp/venv processes=4 threads=2

• Serve static files directly through Apache (Alias directives) rather than through the Python application.
• Combine with the compression and caching techniques from our other Apache guides.
• Consider an alternative like Gunicorn or uWSGI behind Apache’s mod_proxy for very high-concurrency workloads, as some teams find this scales more predictably than mod_wsgi.

Troubleshooting

500 Internal Server Error with no clear message:

• Check error.log: sudo tail -f /var/log/apache2/myflaskapp_error.log. mod_wsgi logs Python tracebacks here.

ModuleNotFoundError for installed packages:

• Confirm python-home points to the correct virtual environment and that the package was installed inside that venv, not globally.

Static files return 404 in Django:

• Run collectstatic and verify the Alias /static/ path matches STATIC_ROOT in settings.py.

Changes to code not reflecting:

• mod_wsgi daemon processes cache the application; restart Apache or touch the .wsgi file to force a reload:

touch /var/www/myflaskapp/myflaskapp.wsgi

Frequently Asked Questions

Do I need mod_wsgi, or can I use Gunicorn instead? Both work. mod_wsgi embeds Python directly into Apache’s process management. Gunicorn runs as a separate process, with Apache acting as a reverse proxy (similar to the Rails/Puma pattern). Gunicorn behind a proxy is increasingly common for containerized deployments; mod_wsgi remains popular for traditional VPS setups already standardized on Apache.

Can I run multiple Python apps on the same Apache server? Yes, using separate WSGIDaemonProcess groups and virtual hosts, each with its own virtual environment and process isolation.

Why does my app work with python app.py but not through Apache? The built-in Flask/Django development server behaves differently from mod_wsgi’s process model — typically the issue is either the python-home path, file permissions, or a missing environment variable that was set locally but not in Apache’s environment.

Is mod_wsgi actively maintained? Yes, mod_wsgi continues to be maintained and is a stable, production-proven choice for serving Python WSGI applications through Apache.

Summary and Key Takeaways

• Python applications communicate with Apache through the WSGI interface, bridged by mod_wsgi.
• Always use a virtual environment and point WSGIDaemonProcess to it via python-home.
• Daemon mode is preferred over embedded mode for production isolation and stability.
• Django requires additional static file configuration (collectstatic + Alias) that Flask doesn’t need out of the box.
• Never run Flask’s or Django’s built-in development server in production — mod_wsgi (or Gunicorn behind a proxy) is the correct approach.
• Check the Apache error log first whenever something goes wrong; Python tracebacks are logged there.

References

• Apache mod_wsgi Documentation
• Apache HTTP Server Documentation
• Django Deployment with mod_wsgi
• Flask Deployment Options

The post How to install and configure Python with Apache appeared first on Abdul Wahab Junaid.

Understanding How PHP Works with Apache

There are two main ways to run PHP alongside Apache:

1. mod_php – PHP runs as an Apache module, embedded directly in Apache’s worker processes. It’s simple to set up but ties PHP’s performance and stability to Apache’s process model, and only works with the older mpm_prefork module.
2. PHP-FPM (FastCGI Process Manager) – PHP runs as an independent process pool, and Apache communicates with it via FastCGI (mod_proxy_fcgi). This is the modern, recommended approach: it’s faster, more memory-efficient, and works with Apache’s high-performance mpm_event module.

This guide focuses primarily on PHP-FPM, since it’s the standard for new deployments, with a note on mod_php for completeness.

Prerequisites

• A Linux server with Apache 2.4+ installed
• Root or sudo access
• Basic familiarity with the command line

Installing PHP-FPM and Connecting It to Apache

Step 1: Install PHP-FPM

Debian/Ubuntu:

sudo apt update
sudo apt install php-fpm php-mysql php-curl php-gd php-mbstring php-xml php-zip

CentOS/RHEL:

sudo dnf install epel-release
sudo dnf install php-fpm php-mysqlnd php-curl php-gd php-mbstring php-xml php-zip

Check the installed version:

php -v

Step 2: Switch Apache to mpm_event and Enable FastCGI Proxy Modules

sudo a2dismod mpm_prefork
sudo a2enmod mpm_event
sudo a2enmod proxy_fcgi
sudo a2enmod setenvif
sudo a2enconf php8.3-fpm
sudo systemctl restart apache2

(Replace 8.3 with your installed PHP version — check with php -v.)

Step 3: Start and Enable PHP-FPM

sudo systemctl start php8.3-fpm
sudo systemctl enable php8.3-fpm
sudo systemctl status php8.3-fpm

Step 4: Configure the Virtual Host

<VirtualHost *:80>
    ServerName example.com
    DocumentRoot /var/www/example.com/public_html

    <Directory /var/www/example.com/public_html>
        AllowOverride All
        Require all granted
    </Directory>

    <FilesMatch \.php$>
        SetHandler "proxy:unix:/run/php/php8.3-fpm.sock|fcgi://localhost/"
    </FilesMatch>

    ErrorLog ${APACHE_LOG_DIR}/example.com_error.log
    CustomLog ${APACHE_LOG_DIR}/example.com_access.log combined
</VirtualHost>

Enable the site and restart Apache:

sudo a2ensite example.com.conf
sudo apachectl configtest
sudo systemctl restart apache2

Step 5: Test PHP Is Working

sudo nano /var/www/example.com/public_html/info.php

<?php
phpinfo();

Visit http://example.com/info.php in a browser. You should see the PHP configuration page. Delete this file after testing — it exposes detailed server information that shouldn’t be public.

sudo rm /var/www/example.com/public_html/info.php

Alternative: Installing mod_php (Legacy Approach)

If you have a specific reason to use mod_php (some legacy applications assume it), here’s the setup:

sudo apt install libapache2-mod-php
sudo a2dismod mpm_event
sudo a2enmod mpm_prefork
sudo a2enmod php8.3
sudo systemctl restart apache2

Note that mod_php requires mpm_prefork, which handles one request per process/thread and generally performs worse under high concurrency than mpm_event with PHP-FPM.

Configuring php.ini for Production

Locate your php.ini file:

php --ini

For FPM, it’s typically at /etc/php/8.3/fpm/php.ini. Key production settings to review:

; Hide PHP version from response headers (security)
expose_php = Off

; Disable dangerous functions if not needed
disable_functions = exec,passthru,shell_exec,system,proc_open,popen

; Limit file upload size appropriately
upload_max_filesize = 20M
post_max_size = 20M

; Set a reasonable execution time limit
max_execution_time = 30

; Enable OPcache for performance
opcache.enable = 1
opcache.memory_consumption = 128
opcache.max_accelerated_files = 10000
opcache.revalidate_freq = 60

; Error handling - never display errors in production
display_errors = Off
log_errors = On
error_log = /var/log/php/error.log

After editing, restart PHP-FPM:

sudo systemctl restart php8.3-fpm

Tuning PHP-FPM Process Management

Edit the pool configuration, typically at /etc/php/8.3/fpm/pool.d/www.conf:

pm = dynamic
pm.max_children = 50
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 10
pm.max_requests = 500

• pm.max_children should be calculated based on available RAM divided by average memory per PHP process.
• pm.max_requests recycles worker processes periodically, helping mitigate memory leaks in long-running scripts.

Restart after changes:

sudo systemctl restart php8.3-fpm

Real-World Use Cases

• WordPress, Drupal, Joomla – the vast majority of CMS platforms run on PHP and Apache.
• E-commerce platforms – Magento and WooCommerce (WordPress-based) rely on this stack heavily.
• Custom web applications – frameworks like Laravel and Symfony run on PHP-FPM behind Apache in most production deployments.
• Shared hosting environments – many hosting providers still default to Apache + PHP-FPM for its balance of compatibility and performance.

Common Mistakes to Avoid

1. Leaving phpinfo() accessible in production – This exposes internal paths, loaded modules, and configuration details useful to attackers.
2. Using mod_php with mpm_event – This combination doesn’t work; mod_php requires mpm_prefork.
3. Not matching the socket path in Apache config to the actual PHP-FPM socket – A common cause of 502 errors after a PHP version upgrade.
4. Ignoring pm.max_children tuning – Leaving it at low defaults on a high-traffic site causes requests to queue and time out.
5. Displaying errors in production – display_errors = On leaks file paths and code structure to visitors; always log errors instead.

Security Best Practices

• Set expose_php = Off to avoid advertising your PHP version in HTTP headers.
• Disable unused, dangerous PHP functions (exec, shell_exec, system) unless your application specifically needs them.
• Keep PHP updated — end-of-life PHP versions no longer receive security patches and are a common attack vector.
• Run PHP-FPM pools under a dedicated, non-privileged user, separate from Apache’s user where possible, for better isolation between sites on shared servers.
• Set strict upload_max_filesize and validate uploaded file types at the application level, not just via PHP config.
• Use open_basedir restrictions to confine PHP scripts to specific directories, limiting the blast radius if a script is compromised.

Performance Optimization Tips

• Always enable OPcache — it caches compiled PHP bytecode, dramatically reducing CPU usage on repeated requests.
• Use PHP-FPM with mpm_event rather than mod_php with mpm_prefork for better concurrency handling.
• Combine with the compression and caching techniques from our other Apache guides for full-stack performance gains.
• Monitor PHP-FPM’s status page (pm.status_path) to track pool utilization and tune pm.max_children based on real traffic data.
• Consider a PHP-level object cache (like Redis or Memcached) for applications with expensive, repeated database queries.

Troubleshooting

502 Bad Gateway:

• PHP-FPM isn’t running, or the socket path in Apache’s config doesn’t match the actual socket. Check with sudo systemctl status php8.3-fpm and verify the path in /etc/php/8.3/fpm/pool.d/www.conf (listen = /run/php/php8.3-fpm.sock).

White screen with no error message:

• display_errors is off (correct for production) but nothing is being logged. Check error_log in php.ini and Apache’s error log.

“File not found” errors for .php files:

• Verify DirectoryIndex includes index.php in your Apache config, and that the FilesMatch handler block is correctly scoped to the virtual host.

High memory usage:

• Review pm.max_children — too high a value on limited RAM causes the OOM killer to terminate processes unpredictably.

Frequently Asked Questions

Should I use PHP-FPM or mod_php for a new project? PHP-FPM, in almost all cases. It’s faster, more memory-efficient, and compatible with Apache’s modern mpm_event MPM.

How do I run multiple PHP versions on the same server? Install multiple PHP-FPM versions side by side (e.g., php8.1-fpm and php8.3-fpm), each with its own socket, and point different virtual hosts to the appropriate socket in their FilesMatch block.

Do I need to restart Apache after changing php.ini? No — restart PHP-FPM instead (sudo systemctl restart php8.3-fpm), since PHP-FPM manages its own processes independently of Apache.

Is PHP still relevant in 2026? Yes. PHP continues to power a substantial share of the web, particularly through WordPress and other CMS platforms, and modern PHP (8.x) with OPcache and PHP-FPM is a solid, performant choice.

Summary and Key Takeaways

• PHP-FPM with mod_proxy_fcgi and Apache’s mpm_event is the modern, recommended way to run PHP on Apache.
• mod_php still works but requires the older, less concurrent mpm_prefork MPM.
• Always disable display_errors and expose_php in production, and remove test phpinfo() files immediately after use.
• Enable OPcache and tune pm.max_children based on your server’s available memory for the best performance.
• Check PHP-FPM’s status and the Apache error log first when diagnosing 502 errors or blank pages.

References

• Apache mod_proxy_fcgi Documentation
• PHP: PHP-FPM Documentation
• PHP: OPcache Documentation
• Apache HTTP Server Documentation

The post How to Install and Configure PHP on Apache appeared first on Abdul Wahab Junaid.

What Does “Dynamic Content” Actually Mean?

Static content is simple: a browser requests a file, and Apache hands it over exactly as it’s stored on disk. Dynamic content is different. Instead of serving a file as-is, Apache runs a script or forwards the request to an application, which generates the response on the fly — often pulling data from a database, session, or API.

Common examples of dynamic content include:

• PHP-driven websites (WordPress, Laravel, custom PHP apps)
• Python applications (Flask, Django) run through WSGI
• Node.js or Java applications proxied through Apache
• CGI or Perl scripts (an older but still-used approach)

Why Use Apache for Dynamic Content?

You might be wondering why not just run your application server directly and skip Apache altogether. In my experience, Apache adds a lot of value as a front-facing layer:

• Battle-tested stability — Apache has been handling production traffic for decades.
• Flexible module system — you can bolt on exactly the functionality you need.
• SSL termination — handling HTTPS at the Apache layer keeps your application code simpler.
• Access control and rewriting — .htaccess and mod_rewrite give you fine-grained control over how requests are handled before they even reach your app.
• Reverse proxy capabilities — Apache can sit in front of application servers written in any language.

Prerequisites

Before diving into configuration, make sure you have:

1. A Linux server (I’ll use Ubuntu/Debian syntax here, with notes for CentOS/RHEL)
2. Apache installed (apache2 on Debian-based systems, httpd on RHEL-based systems)
3. Root or sudo access
4. Basic familiarity with editing configuration files
5. The scripting language or runtime you plan to use already installed (PHP, Python, Node.js, etc.)

Step 1: Install Apache

On Ubuntu/Debian:

sudo apt update
sudo apt install apache2 -y

On CentOS/RHEL:

sudo yum install httpd -y
sudo systemctl enable httpd
sudo systemctl start httpd

Confirm it’s running:

sudo systemctl status apache2

Step 2: Serving PHP Dynamic Content

PHP is probably the most common dynamic content use case for Apache, so I’ll start there.

Install PHP and the Apache PHP module:

sudo apt install php libapache2-mod-php php-mysql -y

Apache automatically enables mod_php on Debian-based installs. Verify it’s active:

apache2ctl -M | grep php

Create a test file:

sudo nano /var/www/html/info.php

<?php
phpinfo();
?>

Visit http://your-server-ip/info.php in a browser. If you see the PHP info page, dynamic PHP content is working. Remove this file once you’ve confirmed it works — leaving phpinfo() publicly accessible is a security risk.

sudo rm /var/www/html/info.php

Step 3: Serving Python Applications with mod_wsgi

For Python apps (Flask/Django), the standard approach is mod_wsgi.

sudo apt install libapache2-mod-wsgi-py3 -y
sudo a2enmod wsgi

Here’s a minimal Flask app I use for testing:

# /var/www/myapp/app.py
def application(environ, start_response):
    status = '200 OK'
    output = b'Hello from dynamic Python content!'
    response_headers = [('Content-type', 'text/plain'),
                         ('Content-Length', str(len(output)))]
    start_response(status, response_headers)
    return [output]

Then configure a virtual host:

<VirtualHost *:80>
    ServerName python.example.com
    WSGIDaemonProcess myapp threads=5
    WSGIScriptAlias / /var/www/myapp/app.py

    <Directory /var/www/myapp>
        WSGIProcessGroup myapp
        WSGIApplicationGroup %{GLOBAL}
        Require all granted
    </Directory>
</VirtualHost>

Enable the site and restart:

sudo a2ensite python-app.conf
sudo systemctl restart apache2

Step 4: Serving Node.js Apps via Reverse Proxy

Apache doesn’t run Node.js directly, but it can proxy requests to a Node process running on a local port. This is my preferred method for Node-based dynamic content.

Enable the proxy modules:

sudo a2enmod proxy proxy_http

Configure the virtual host:

<VirtualHost *:80>
    ServerName node.example.com
    ProxyPreserveHost On
    ProxyPass / http://127.0.0.1:3000/
    ProxyPassReverse / http://127.0.0.1:3000/
</VirtualHost>

Restart Apache:

sudo systemctl restart apache2

Step 5: Directory and Permissions Configuration

Dynamic content often needs write access for logs, uploads, or cache directories. I always double-check ownership:

sudo chown -R www-data:www-data /var/www/myapp
sudo chmod -R 755 /var/www/myapp

Avoid chmod 777 — it’s a common shortcut that opens serious security holes.

Real-World Use Cases

• E-commerce platforms running PHP-based Magento or WooCommerce need dynamic product pages, cart sessions, and payment processing.
• SaaS dashboards built in Django or Flask rely on Apache to route requests and manage SSL.
• Microservices written in Node.js often sit behind Apache as a unifying reverse proxy, letting you consolidate multiple backend services under one domain.

Troubleshooting Common Issues

500 Internal Server Error — Check the Apache error log:

sudo tail -f /var/log/apache2/error.log

This almost always points to a permissions issue, a missing module, or a syntax error in your script.

Blank Page with No Error — For PHP, make sure display_errors is enabled in php.ini while debugging:

display_errors = On
error_reporting = E_ALL

502 Bad Gateway on Proxy Setups — This usually means the backend application (Node.js, Python) isn’t running or isn’t listening on the port you configured. Double-check with:

sudo netstat -tulnp | grep 3000

Module Not Loading — Verify with apache2ctl -M and check that you ran a2enmod followed by a restart, not just a reload.

Security Best Practices

• Disable directory listing with Options -Indexes in your virtual host config.
• Keep PHP, Python, and Node runtimes patched and updated.
• Use mod_security as a web application firewall layer if you’re handling sensitive data.
• Never expose debug pages like phpinfo() in production.
• Run application processes as a non-root user.

Performance Optimization Tips

• Use mod_deflate to compress responses.
• Enable mod_expires for caching static assets referenced by dynamic pages.
• For PHP, switch to PHP-FPM with mod_proxy_fcgi instead of mod_php — it’s more efficient under concurrent load.
• Tune MaxRequestWorkers in your MPM configuration to match your server’s resources.

FAQs

Do I need mod_php for PHP to work? No — you can also run PHP through PHP-FPM with mod_proxy_fcgi, which is generally faster and more scalable for production.

Can Apache serve multiple dynamic languages at once? Yes. You can run PHP on one virtual host, proxy to Python on another, and proxy to Node.js on a third — all from the same Apache instance.

Is Apache the best choice for dynamic content compared to Nginx? Both are capable. Apache’s .htaccess flexibility and module ecosystem make it appealing for shared hosting and legacy apps, while Nginx is often favored for raw performance in reverse proxy scenarios. The right choice depends on your existing stack and team familiarity.

Summary and Key Takeaways

Setting up Apache for dynamic content isn’t complicated once you understand the moving parts: pick the right module or proxy method for your language, configure your virtual host correctly, and lock down permissions and error handling before going live. Whether you’re running classic PHP, a Python WSGI app, or proxying to Node.js, Apache gives you a stable, well-documented front end to build on.

References

• Apache HTTP Server Documentation
• Apache mod_wsgi Documentation
• Apache mod_proxy Documentation

The post How to Set Up Apache for Serving Dynamic Content appeared first on Abdul Wahab Junaid.