On this page
Why Apache still matters
Apache HTTP Server has run websites for decades and remains common, especially with PHP applications, older CMS installs and software that relies on .htaccess files. Apache configuration covers virtual hosts, modules, rewrite rules, PHP handlers and performance settings, set up so the server is stable rather than mysteriously slow.
We do not treat Apache as something to be replaced by default. If your application depends on it and works, making Apache run well is often the most sensible option.
Who needs Apache work
- Businesses running an older PHP application or CMS that depends on .htaccess rules.
- Agencies with client sites on a server that has grown into a tangle of virtual hosts.
- Teams whose server runs out of memory under load because of the default process model.
- Mixed stacks where Apache and another web server both need to share ports 80 and 443.
A classic symptom is a server where Apache and Nginx both try to start on the same ports after an update, and every site goes down. Settling which server owns which role fixes this permanently.
What’s included
- Virtual hosts organised one per site, with clear naming and logging.
- Only necessary modules enabled; unused ones disabled.
- Rewrite rules reviewed, tidied and tested against important URLs.
- PHP handled through PHP-FPM with the event MPM where the application allows, instead of the older prefork model.
- Worker and connection limits sized to the server’s memory.
- HTTPS with Let’s Encrypt, redirects and security headers.
- Optional setup with Nginx in front for TLS and static files, and Apache behind for the application.
How we work
- Audit the existing configuration, enabled modules, logs and resource usage.
- Agree what should stay on Apache and whether a front proxy would help.
- Make changes in a copy, validate the syntax and test in staging where available.
- Apply with a graceful restart and confirm each site from outside the server.
- Document the layout, the PHP versions per site and how to add a new one.
Tools and stacks
We work with Apache 2.4 on Ubuntu, Debian and RHEL-family systems, PHP-FPM with multiple PHP versions side by side, and Let’s Encrypt for certificates. Where it helps, we put Nginx in front as a reverse proxy, or place the whole server behind Cloudflare. Control-panel servers are handled with care so their own configuration management is not overwritten.
What affects timeline and cost
A single site with a clean configuration is quick. Time increases with the number of virtual hosts, complex or conflicting rewrite rules, several PHP versions, control panels and the amount of testing needed for legacy applications without staging copies.
Where there is no staging copy of a legacy application, we can create a temporary one on a separate server for testing. That adds a little time up front but greatly reduces the risk of changing configuration on a live site that nobody fully understands.
Keep Apache, add Nginx, or switch
Clients often ask whether they should move away from Apache. There is no single answer, so we lay out the options plainly:
| Option | When it makes sense | What to consider |
|---|---|---|
| Keep Apache, tuned | The application depends on .htaccess or Apache modules and performs acceptably | Lowest risk; needs sensible worker and PHP-FPM settings |
| Nginx in front, Apache behind | You want faster static files and central TLS without rewriting rules | Two services to maintain, but each does what it is good at |
| Switch fully to Nginx | Rewrite rules are simple and the team prefers Nginx | Rules must be translated and tested carefully before cutover |
For most legacy PHP applications, tuning Apache or placing Nginx in front delivers the practical gains without the risk of breaking years of accumulated rewrite rules. We only recommend a full switch when the benefits are clear and the testing effort is justified.
Whichever route you take, the result is documented: which server listens on which ports, how requests flow between them and where each site’s configuration lives. That clarity alone prevents the kind of port conflicts that can take every site on a server offline after a routine package update.
Common mistakes
- Leaving every module enabled, including ones with known risks or no purpose.
- Using mod_php with prefork on a busy site, which consumes memory quickly.
- Piling rewrite rules into .htaccess files until nobody can tell which one applies.
- Running Apache and Nginx side by side without deciding which one listens on the public ports.
Related: Nginx Configuration, Reverse Proxy Setup and Server Migration. Browse Cloud & Server Management, read the cloud and server guide, or contact us.
Frequently asked questions
Should we switch from Apache to Nginx?
Not necessarily. If Apache is configured well and the application depends on it, keeping it is often the lowest-risk choice. Putting Nginx in front can give many of the benefits without a rewrite.
Can you run several PHP versions on one Apache server?
Yes, using PHP-FPM pools per site. That lets older sites stay on the version they need while newer ones move ahead.
Do you work on servers with cPanel or other control panels?
Yes, carefully. Control panels regenerate configuration, so changes are made through the panel’s supported methods where possible.
Our Apache server keeps running out of memory. Can you help?
Usually. The cause is often the process model or worker limits set too high for the available memory, which we measure and adjust.
Can Apache handle HTTPS and HTTP/2?
Yes. Modern Apache supports HTTP/2 and strong TLS settings, especially when paired with the event MPM and PHP-FPM. We configure and test both from outside the server.
Talk to us about apache configuration
Legacy and mixed stacks configured, tuned and kept stable.