Nginx support and configuration

Nginx is the web server and reverse proxy we put into production most often: lightweight, fast and predictable even when your traffic isn’t. The difference between an Nginx that shrugs off a spike and one that starts returning 502s isn’t the software, it’s the configuration: workers, buffers, cache and timeouts need to be calibrated to the traffic you actually get. That’s exactly what we do, and we leave every choice written down and justified.

Overview

We work on Nginx at every stage: first install, reviewing a server that’s already in production, clearing a bottleneck or migrating from another web server. The starting point is always the reality of your traffic - how many requests, distributed how, to which backends - because a directive that’s right for a blog is wrong for an e-commerce site with carts and sessions.

We handle reverse proxying and load balancing, multi-layer caching, HTTP/2 and HTTP/3, TLS termination and hardening. When Nginx has inherited years of layered changes, we bring the configuration back to clean, commented blocks under version control. And if the problem isn’t Nginx but the application behind it, we tell you so with the data to back it up instead of selling more tuning: it happens more often than you’d think, and knowing it upfront saves you unnecessary spend.

Typical problems we solve

• The site goes down during traffic spikes → we put Nginx in front of the application with micro-caching and rate limiting to absorb the surges.
• High TTFB despite a well-sized server → we enable full-page cache and asset caching, with correct invalidation and bypass rules.
• Intermittent 502/504 errors behind the proxy → we fix timeouts, buffering and keepalive settings to the backends and verify the result under load.
• A migration from Apache stalled by fear of .htaccess rules → we translate rewrites and redirects into an equivalent Nginx configuration, tested on staging.
• Expired certificates or outdated TLS flagged by browsers → we configure modern ciphers with HSTS and automate certificate renewal.
• Bots and scrapers saturating CPU and bandwidth → we apply rate limiting, block sensitive paths and filter anomalous requests.
• A layered configuration nobody dares touch anymore → we rewrite it into readable, versioned, documented blocks.

What’s included

• Reverse proxy and load balancing: Nginx in front of PHP-FPM, Node.js, containers or multiple backends, with health checks, weights and failover.
• Multi-layer caching: full-page cache, micro-caching and static asset caching, with bypass rules for restricted areas, carts and APIs.
• HTTP/2 and HTTP/3 (QUIC): modern protocols and Brotli/gzip compression to cut perceived latency, especially on mobile.
• TLS and certificates: up-to-date ciphers, HSTS, OCSP stapling and automatic renewal with Let’s Encrypt.
• Performance tuning: worker processes, keepalive, buffers, timeouts and OS limits calibrated to your real load, not copied from a forum post.
• Hardening: security headers, rate limiting, a reduced exposed surface and blocking of malformed requests.
• Migrations and hybrid setups: moving from Apache to Nginx, or Nginx as a caching proxy in front of Apache where legacy rules need to stay in place.

Stack and technologies

We work with Nginx from the official repositories, in the stable or mainline branch depending on your needs, mainly on Debian and Ubuntu; on request we also work on AlmaLinux, Rocky Linux and Arch Linux. Behind the proxy we usually find PHP-FPM (often running Laravel, WordPress or Magento), Node.js, or services in Docker containers.

For certificates we use Let’s Encrypt with automatic renewal and expiry checks; for compression, Brotli and gzip; for observability we export Nginx metrics to the monitoring stack, so spikes show up in the graphs rather than in complaints. We host servers on Google Cloud as our first choice, with AWS and DigitalOcean as alternatives. Every configuration file ends up in a repository, with a history of changes and the reasoning behind each one.

A real-world example

A WooCommerce store was throwing 502 errors on every promotional campaign: the web server passed every request straight to PHP-FPM, which maxed out its workers within minutes. We put Nginx in as a reverse proxy with one-second micro-caching on catalogue pages, excluding cart, checkout and account area from the cache rules, and recalibrated the PHP-FPM pool, buffers and timeouts against the numbers observed during peaks.

At the next campaign, the server absorbed the traffic with no errors, and response times on catalogue pages dropped sharply, because most requests no longer touched PHP at all. The client received the commented configuration in their own repository, along with a report explaining what changed and why.

Who it’s for

• E-commerce and editorial sites with irregular traffic, where a spike shouldn’t turn into an outage.
• SaaS and web applications exposing APIs behind a reverse proxy that need timeouts, buffering and limits done properly.
• Agencies managing servers for clients who want readable configurations instead of black boxes.
• Teams that have inherited an Nginx setup configured by someone who’s no longer around, and want to understand it again.

How we work

Before touching a single line, we measure: logs, metrics, backend behaviour under load. Then we propose the smallest change that solves the problem, test it on staging where the environment allows it, and agree the production release window with you. You get a single point of contact who answers with substance, and at the end of the work you’re left with open, commented configurations: no lock-in to us, anyone can pick up where we left off.

One-off work is billed at our hourly rate, while for ongoing maintenance hour packages, which never expire, are the better fit. Coverage and response priorities are described on the response times page; quotes are free and arrive within one business day.