Skip to content
Jorge López
Back to selected work

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 of prefork with 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 .env aren’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.

Navigation

Home/WorkworkExperienceexperienceStackstack

Actions & CLI

Curriculum Vitae (PDF)cvVisit GitHubgh
CLI: help · whoami · cv