fastify-production

Fastify Production Hardening

When helping a user prepare a Fastify application for production, follow every section below. These are non-negotiable requirements for a production-grade Fastify deployment. Do not skip sections. If the user's codebase is missing any of these, flag it explicitly and provide the fix.

Reverse Proxy (Non-Negotiable)

NEVER allow a Fastify server to be exposed directly to the internet. This is an explicit anti-pattern called out by the Fastify team themselves. ALWAYS deploy Fastify behind a reverse proxy such as Nginx, HAProxy, AWS ALB, GCP Load Balancer, or Cloudflare.

The reverse proxy is responsible for:

• TLS termination -- Node.js is significantly less efficient at encryption than dedicated proxy software. Offloading TLS to the proxy frees the event loop for request handling.
• Static file serving -- serve assets from the proxy layer, not from Fastify.
• Load balancing -- distribute traffic across multiple Fastify instances.
• Connection management -- handle keep-alive, timeouts, and slow clients at the proxy layer.

When Fastify runs behind a proxy, configure trustProxy so that request.ip and request.hostname resolve correctly from forwarded headers:

const app = fastify({
  trustProxy: true // trusts all proxies
})

// Or be specific with IP/CIDR:
const app = fastify({
  trustProxy: '10.0.0.0/8'
})

Without trustProxy, the X-Forwarded-For, X-Forwarded-Host, and X-Forwarded-Proto headers can be spoofed by any client. Always set this when behind a proxy. Never set it when not behind a proxy.

Security Headers & Plugins

@fastify/helmet (Required)

Register @fastify/helmet on every production Fastify instance. It sets critical security headers including Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security, and others.

Register it early, before any route definitions, so that headers apply to all responses including error responses: