2025 – 2026 · Zendata · Business applications (NDA)
Linux servers for Laravel applications in production
I audited and reconfigured the production Ubuntu servers behind the team's applications: Apache with mpm_event and HTTP/2, PHP-FPM, OPcache, InnoDB sized to the RAM, queues under Supervisor, and hardening.
- Ubuntu
- Apache
- PHP-FPM
- OPcache
- MySQL/MariaDB
- Supervisor
- Hardening
My role
Auditing and configuring production servers; moving blocking tasks to queues.
Evidence
What I did
- Audited production Ubuntu servers with 8 GB of RAM.
- Apache from mpm_prefork to mpm_event, with HTTP/2.
- PHP split out of Apache with PHP-FPM and capped worker pools.
- OPcache, InnoDB buffer pool, and swappiness tuned to the available memory.
- Blocking tasks moved to Laravel queues, with workers under Supervisor.
- Apache and PHP hardening, and protection of sensitive files.
Still to be measured
- Latency, memory, and swap before and after the changes.
Next step
- A performance baseline and monitoring.
- Turn the configuration into code (Ansible or Terraform) and containers.
The idea
On an 8 GB server, Apache, PHP, the database, and the workers all share the same machine. The work was about dividing memory on purpose: every component gets a limit, so a traffic spike becomes a short wait instead of an outage.
What I changed
- Apache
mpm_event+ PHP-FPM instead ofpreforkwith embedded PHP: less memory per connection and an explicit cap on PHP processes. It also enabled HTTP/2. - Database sized to the machine: the InnoDB buffer pool gets what’s left after PHP, not “all the RAM”.
- Low
vm.swappiness: the server favors RAM over swap. - OPcache: PHP stops recompiling scripts on every request.
- Queues with Supervisor: what used to make users wait moved to the background, and Supervisor keeps the workers alive.
- Hardening: Apache and PHP don’t advertise their versions, there are defensive headers, and files like
.envaren’t reachable.
What I don’t claim
I didn’t measure performance before the changes, so I don’t publish improvement percentages. The next step is a baseline and monitoring, and turning this configuration into reproducible infrastructure: that’s exactly the path toward DevOps I’m on.