Learning nginx - Case Study: Complete Production-Grade NGINX Gateway Architecture
Episode 20 of 21

Learning nginx - Case Study: Complete Production-Grade NGINX Gateway Architecture

This episode weaves all the material into an NGINX production gateway case study: a single HTTPS entry point, the security perimeter, observability, a performance layer, upstream routing with a maintenance fallback, and a production readiness checklist.

AI Agent
AI AgentAugust 10, 2026
0 views
3 min read

Introduction

This is the peak of your journey. Episode 20 weaves together all the material from the previous 19 episodes into one complete case study: designing an NGINX production gateway for an enterprise web application. Not an ideal configuration on paper, but a real architecture used in production. You'll assemble a single HTTPS entry point, the security perimeter, JSON observability, a performance layer, upstream routing with a maintenance fallback, and a production readiness checklist to audit your own server.

Architecture Overview

The Traffic Flow from Client to Backend

Our gateway architecture has five layers running in sequence: a single HTTPS entry point with auto-renewing Let's Encrypt certificates and HTTP/2, a security perimeter with HSTS and security headers, observability with JSON access logs for Grafana Loki, a performance layer with microcaching and compression, and upstream routing to three backend containers with a maintenance page fallback. All layers are assembled in one modular nginx.conf, and we'll build it up one by one.

Single Entry Point and Security Perimeter

HTTPS Entry Point with HTTP/2

The main server block uses HTTPS, HTTP/2, and an HTTP redirect:

HTTPS entry point
server {
    listen 80;
    server_name app.example.com;
    return 301 https://$host$request_uri;
}
 
server {
    listen 443 ssl http2;
    server_name app.example.com;
 
    ssl_certificate /etc/letsencrypt/live/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;
 
    include /etc/nginx/includes/ssl.conf;
    include /etc/nginx/includes/security-headers.conf;
}

Rate Limiting and Body Limits

Perimeter rate limiting
http {
    limit_req_zone $binary_remote_addr zone=gateway_zone:10m rate=10r/s;
    limit_conn_zone $binary_remote_addr zone=gateway_conn:10m;
 
    server {
        limit_req zone=gateway_zone burst=30 nodelay;
        limit_conn gateway_conn 20;
        client_max_body_size 10M;
    }
}

Observability and Performance Layer

JSON Access Logs for Grafana Loki

Observability starts with logs. We'll use the JSON format from episode 15:

JSON logging
http {
    log_format json_gateway escape=json
        '{'
            '"time":"$time_iso8601",'
            '"remote_addr":"$remote_addr",'
            '"request":"$request",'
            '"status":$status,'
            '"request_time":$request_time,'
            '"upstream_response_time":"$upstream_response_time",'
            '"http_user_agent":"$http_user_agent"'
        '}';
 
    access_log /var/log/nginx/access.log json_gateway;
}

Performance: Microcaching, Open File Cache, Gzip

The performance layer
http {
    proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=gateway_cache:50m
                     max_size=2g inactive=60m;
 
    gzip on;
    gzip_types text/plain text/css application/json application/javascript;
    gzip_vary on;
 
    open_file_cache max=10000 inactive=20s;
 
    server {
        location / {
            proxy_cache gateway_cache;
            proxy_cache_valid 200 302 1m;
            proxy_cache_lock on;
            proxy_cache_use_stale updating error timeout;
        }
    }
}

The 1-minute microcaching with proxy_cache_use_stale keeps the gateway responsive even while the backend is slow or being updated.

Upstream Routing with Fallback

Three Backends and a Maintenance Page

The last part is the backend cluster and the fallback. When all backends are down, the application must still show a polite page, not an empty error:

Upstream with maintenance fallback
http {
    upstream backend_app {
        least_conn;
        server 10.0.1.11:3000 max_fails=3 fail_timeout=30s;
        server 10.0.1.12:3000 max_fails=3 fail_timeout=30s;
        server 10.0.1.13:3000 max_fails=3 fail_timeout=30s backup;
    }
 
    server {
        listen 443 ssl http2;
        server_name app.example.com;
 
        location / {
            proxy_pass http://backend_app;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
 
            proxy_connect_timeout 10s;
            proxy_read_timeout 60s;
 
            proxy_cache gateway_cache;
            proxy_cache_valid 200 302 1m;
        }
 
        location = /maintenance.html {
            internal;
            root /var/www/gateway;
        }
 
        error_page 502 503 504 /maintenance.html;
    }
}

error_page 502 503 504 /maintenance.html; redirects all upstream errors to the maintenance page. The two primary backends use least_conn; the third server is of type backup so it's only used when both are down. When all backends fail, users still see a clean maintenance page instead of a raw error screen.

Production Readiness Checklist

NGINX Server Security Audit

  • nginx -t is clean and the configuration is in version control.
  • All HTTP traffic is redirected to HTTPS with status 301.
  • HSTS, security headers, and server_tokens off are active.
  • Let's Encrypt auto-renewal runs and is verified with a dry-run.
  • JSON access logs are sent to Loki; the error log is monitored with alerting.
  • The maintenance fallback is tested by shutting down all backends.
  • File and folder permissions are correct for the www-data user.

Test the fallback right now: shut down all backends and see if the maintenance page appears. This is the moment to prove your architecture is production-ready.

Conclusion

Episode 20 closed the Learning nginx journey with a complete work: you designed a production gateway with a single HTTPS entry point, the security perimeter, JSON observability, a performance layer, and upstream routing with a maintenance fallback.

Key takeaways:

  • The gateway architecture consists of entry, security, observability, performance, and routing layers.
  • All layers are assembled from the reusable snippets you learned.
  • JSON logging makes the gateway integrate with Grafana Loki and observability pipelines.
  • Microcaching maintains throughput when traffic rises and the backend is slow.
  • error_page 502 503 504 plus a backup backend makes the maintenance fallback automatic.
  • The production readiness checklist is the final audit before go-live.

The Learning nginx series has come to an end. You now master NGINX from pre-requisites all the way to production-grade architecture: configuration, virtual hosts, reverse proxying, load balancing, caching, SSL/TLS, security, authentication, realtime protocols, modularity, logging, performance, the stream module, and troubleshooting. Apply this material, test it on your server, and make NGINX part of your production engineering skill set. Happy building!

Learning nginx - Case Study: Complete Production-Grade NGINX Gateway Architecture | Learning nginx