Skip to content
Lizely

Nginx Config Generator

Create a narrow static-site Nginx HTTP server block from validated domain, root, fallback, cache and gzip choices with explicit testing and TLS limitations.

Privacy: your files never leave your device. All processing happens locally in your browser.

How to use

  1. 1.Enter one exact domain, a safe absolute document root and a cache duration, then choose static 404 or SPA fallback deliberately.
  2. 2.Generate the block and review every directive against the installed Nginx modules, deployment paths and cache strategy.
  3. 3.Back up the active configuration, place the fragment in context, run nginx -t and test representative requests before reload.

About Nginx Config Generator

Nginx Config Generator creates a bounded HTTP server block for a simple static website or single-page application. Enter one domain, an absolute document-root path, a static asset cache duration, and optional SPA fallback and gzip choices. The output stays local in the browser and is intended for review inside a larger Nginx installation.

The generated block listens on IPv4 and IPv6 port 80 and selects one exact server_name. It does not add a wildcard, alternate www host or regular expression because those choices affect virtual-host routing and certificate coverage. If several names should serve or redirect, design that behavior explicitly rather than assuming a generator can infer ownership.

The document root must be an absolute POSIX path made from bounded safe path characters. Semicolons, braces, variables, whitespace and shell-like syntax are rejected so user input cannot create extra directives. The path still has to exist on the target server with correct ownership and read permissions; the browser cannot inspect those facts.

For an ordinary static site, location / uses try_files with the requested URI, a directory form and an explicit 404 fallback. For an SPA, the final fallback becomes /index.html so client-side routing can receive unknown application paths. Do not enable SPA fallback for a normal content site, because returning the home shell with status 200 for missing resources can hide broken URLs and damage error semantics.

A separate case-insensitive asset location covers a small fixed extension list for CSS, JavaScript, common images, icons and WOFF2 fonts. The expires directive uses the selected 1-to-365-day duration, and Cache-Control public is added. Version or fingerprint long-lived assets before selecting a high duration; otherwise visitors may keep stale files after a deployment.

Optional gzip enables the standard filter, adds Vary: Accept-Encoding and lists CSS, JavaScript, JSON and SVG types. HTML is handled by Nginx gzip behavior without needing to appear in gzip_types. Compression can create side-channel concerns for secrets reflected into compressed responses, and precompressed assets need different configuration. Measure the real site and security context.

TLS is deliberately excluded. Correct HTTPS setup depends on certificate paths, renewal tooling, supported protocols, redirects, proxy or CDN topology and HSTS policy. Inventing certificate locations would produce dangerous false confidence. Configure HTTPS through the hosting platform or a reviewed server procedure, then test HTTP-to-HTTPS behavior separately.

The output also omits PHP, FastCGI, reverse proxying, WebSockets, uploads, authentication, rate limits, custom errors, MIME include paths, logging and security headers. It is a static-site fragment, not a production baseline for every application. Add only directives required by the actual architecture and official module documentation.

Eight official-documentation fixtures cover both listen forms, exact server_name, root, static and SPA try_files fallbacks, asset expiration and gzip types. Negative tests reject scheme-bearing domains, injection-shaped roots and cache durations outside the contract. Exact block boundaries are asserted so duplicated server blocks cannot pass.

Before changing production, save the current configuration and record the active include chain. Place the reviewed file in the correct context, then run nginx -t against the full configuration. A successful syntax test does not prove file permissions, DNS, application routing or certificate behavior, so request representative paths afterward.

Reload rather than abruptly stopping the service when the platform procedure supports it, and keep a recovery shell open. If the syntax test fails, do not reload. If requests fail after reload, restore the backup and inspect error logs. Permanent cache and routing mistakes can affect visitors even when Nginx remains online.

Use the generator when the problem really is a small static origin. For managed hosting, containers, Kubernetes ingress or a CDN, the correct configuration surface may be elsewhere. The most maintainable result is the smallest reviewed config that matches current deployment evidence.

Methodology & sources

A plain public domain, safe absolute POSIX root and integer cache duration are validated before assembling one fixed HTTP server block with exact listen, root, index, try_files, bounded asset caching and optional documented gzip lines; TLS and application backends are excluded.

Frequently asked questions

Related tools

SEO & Webmaster guides

View all