Your files never leave your device. All processing happens locally in your browser.
How do I generate an nginx server config?
Pick a server type — static site, single-page app, reverse proxy, PHP/WordPress or load balancer — then fill in your domain, upstream or root path, and toggle SSL, security headers, gzip, HSTS, caching and rate limiting. A production-ready nginx config is written live as you type. Copy it or download nginx.conf, then test with nginx -t and reload. Everything is built in your browser; nothing is uploaded.
Five server types: static, SPA, reverse proxy, PHP-FPM, load balancer
Modern SSL/TLS (TLSv1.2/1.3, OCSP stapling) with an HTTP→HTTPS redirect
Gzip, long-lived static caching, client_max_body_size and optional rate limiting
www↔non-www canonical redirect and a Let’s Encrypt ACME challenge location
Copy or download nginx.conf — 100% client-side, nothing uploaded
What is
Nginx Server Block
An nginx server block (sometimes called a virtual host) is the configuration that tells nginx how to handle requests for a given domain — which port to listen on, the TLS certificates to use, and how to serve the site, whether from disk (root + index), via a reverse proxy (proxy_pass), php-fpm (fastcgi_pass) or an upstream pool of backends.
Static serves files from a root directory, a reverse proxy forwards requests to an app on a port with proxy_pass, and PHP passes scripts to php-fpm via fastcgi_pass.
A static or SPA config sets a root and index and uses try_files to serve files from disk (an SPA falls back to index.html so client-side routing works). A reverse proxy config has a location / that uses proxy_pass to forward requests to an application listening on a port — for example a Node, Python or Go server — and sets the Host, X-Real-IP, X-Forwarded-For and X-Forwarded-Proto headers so the backend sees the real client. A PHP/WordPress config serves static files but passes .php requests to php-fpm with fastcgi_pass over a Unix socket. The Nginx Config Generator emits the correct location blocks for whichever type you pick.
Listen on 443 with ssl, point ssl_certificate and ssl_certificate_key at your certs, and add a port-80 server block that returns 301 to https.
A secure nginx setup uses two server blocks: one listening on port 80 that redirects every request with return 301 https://$host$request_uri, and the main block listening on 443 ssl with http2 on, ssl_certificate and ssl_certificate_key paths, ssl_protocols TLSv1.2 TLSv1.3, a modern intermediate cipher suite and OCSP stapling. When SSL is enabled, the generator also adds an HSTS header and a Let’s Encrypt /.well-known/acme-challenge/ location. You must obtain the certificates first (for example with certbot) so the certificate paths exist before you reload nginx.
X-Frame-Options, X-Content-Type-Options nosniff, Referrer-Policy, Permissions-Policy and, over HTTPS, Strict-Transport-Security (HSTS) — plus an optional Content-Security-Policy.
A hardened nginx server adds X-Frame-Options SAMEORIGIN to limit framing, X-Content-Type-Options nosniff to stop MIME sniffing, a Referrer-Policy such as strict-origin-when-cross-origin, a Permissions-Policy locking down geolocation/microphone/camera, server_tokens off to hide the version, and over HTTPS a Strict-Transport-Security (HSTS) header with a long max-age and includeSubDomains. The generator can also emit a Content-Security-Policy starter, which you should tighten to match your real assets before production. Each add_header uses the always flag so it is sent on error responses too.
Yes — it is completely free with no signup, and your domain, paths and options never leave your browser.
The Nginx Config Generator is free with no account or limits. The whole config is assembled locally by a small pure string builder in your browser, so your domain, upstream hosts, root paths and every option you choose stay on your device — nothing is uploaded, logged or stored — and it keeps working offline once the page has loaded. Always review the output and test it with nginx -t before reloading; it is a strong starting point, not a security audit.
Detailed Explanation
🔧Technical Details
Five Server Types and the Location Blocks They Emit
The Nginx Config Generator builds a complete server block from a friendly form, choosing the right routing for one of five server types. A static site sets a root and index and serves files with try_files $uri $uri/ =404; a single-page app uses try_files $uri $uri/ /index.html so client-side routing falls back to the app shell; a reverse proxy emits a location / with proxy_pass to an upstream app on a port plus the Host, X-Real-IP, X-Forwarded-For, X-Forwarded-Proto and X-Forwarded-Host headers; a PHP/WordPress config passes .php requests to php-fpm with fastcgi_pass over a Unix socket and denies hidden files; and a load balancer declares an upstream pool with round-robin, least_conn or ip_hash balancing and keepalive, then proxies to it.
Static: root + index with try_files $uri $uri/ =404
SPA: try_files fallback to /index.html for client routing
PHP: fastcgi_pass to php-fpm socket, hidden-file deny rule
Load balancer: upstream pool (round-robin / least_conn / ip_hash) with keepalive
⚙️Methodology
Modern SSL/TLS, Redirects and Security Hardening
When SSL is enabled the generator emits a dedicated port-80 server block that redirects all HTTP traffic with return 301 https://$host$request_uri, plus an optional Let’s Encrypt /.well-known/acme-challenge/ location for certbot webroot validation. The main block listens on 443 with http2 on, sets ssl_certificate and ssl_certificate_key to the /etc/letsencrypt/live paths, and configures ssl_protocols TLSv1.2 TLSv1.3, an intermediate cipher suite, session caching and OCSP stapling. Security hardening adds X-Frame-Options, X-Content-Type-Options nosniff, Referrer-Policy, Permissions-Policy and server_tokens off, an optional Strict-Transport-Security (HSTS) preload header over HTTPS, and an optional Content-Security-Policy starter. A separate canonical redirect block handles www↔non-www so one hostname is authoritative.
HTTP→HTTPS redirect block plus ACME challenge location for certbot
TLSv1.2/1.3, intermediate ciphers, session cache and OCSP stapling
HSTS preload header sent only over HTTPS, with the always flag
X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, server_tokens off
www↔non-www canonical 301 redirect to a single authoritative host
⚠️Limitations
Performance Options, Client-Side Build and Honest Caveats
Performance and tuning options include gzip with a sensible type list and compression level, long-lived immutable caching for hashed static assets (CSS/JS/fonts/images), a configurable client_max_body_size for uploads, access and error logging per domain, and optional request rate limiting. The entire config is assembled by a pure string builder in the browser, so the domain, upstream hosts, paths and every toggle stay on the device — nothing is uploaded, logged or stored, and the tool works offline once cached. The output is explicit that it is a strong starting point rather than a security audit: it must be tested with nginx -t before reloading, certificate paths assume certs were already obtained with certbot, and directives such as limit_req_zone and the WebSocket connection-upgrade map belong in the http {} context of the main nginx.conf, not inside the server {} block.
