Skip to main content

Production Nginx Config Generator for Apps

Create a production Nginx server block for a static HTML site or a Node.js/Python app. Set the domain, document root or application port, tune security and proxy controls, then copy the config and ordered Ubuntu/Debian commands. The tool is free and runs in your browser, so every value stays on your device.

Production configuration workspace

Static HTML or Node.js/Python reverse proxy

Local-only generation
Deployment type

Static website details

Required values for the server block.

Enter the hostname only, without https://, a port, or a path.

Absolute server path containing index.html and the site assets.

Preferences save automatically in this browser

Configuration and Ubuntu/Debian commands are generated locally. Nothing is uploaded.

Ready for production settings

Choose a deployment type, enter the required values, and generate the Nginx file plus four ordered server steps.

  • Syntax-safe server block
  • Quoted configuration install command
  • Optional Certbot HTTPS step

Static or Reverse Proxy

Generate a document-root server for HTML or proxy a Node.js/Python app through a private host and port.

Production Controls

Edit TLS, HSTS, headers, gzip, caching, WebSockets, buffering, timeouts, rate limits, logs, IPv6, and UFW output.

Four Ordered Steps

Copy package setup, a quoted config install, syntax test and reload, then optional Certbot HTTPS commands.

Preferences Restored

Every control saves to browser storage and returns on the next visit. Reset returns all choices to production defaults.

How to generate and install an Nginx configuration

Enter the public hostname and choose either a static document root or a private application port. The generator validates every value before it emits Nginx syntax. It then pairs the file with commands that install Nginx, write the exact configuration through a non-expanding heredoc, test the complete installed setup, reload safely, and request HTTPS only when selected.

  1. Select Static website for HTML files or App / API for Node.js and Python.
  2. Enter the domain, then set the root directory or private application port.
  3. Open Advanced Production Settings to edit HTTPS, headers, cache, proxy, timeout, and rate-limit behavior.
  4. Click Generate production config and review every production note.
  5. Copy the file or download the .conf, then run deployment steps 1 through 4 in order.
  6. Do not reload Nginx unless sudo nginx -t reports a successful syntax test.

What a production Nginx server block needs

A deployable site file connects a public server_name to either a filesystem root or an upstream proxy_pass. This generator also emits request limits, logs, compression, response headers, hidden-file protection, and explicit forwarding headers. For app mode, the upstream URL has no trailing URI, so Nginx preserves the original request path instead of replacing it.

Nginx defines proxy_pass as setting “the protocol and address of a proxied server.” See the officialproxy module reference.

Nginx defaults client_max_body_size to 1 MB; this tool chooses 10 MB so common forms and JSON uploads do not fail unexpectedly with HTTP 413. The app preset keeps the documented 60-second proxy read and send timeouts, while the connect timeout is reduced to 10 seconds so a dead local process fails promptly. All three remain editable.

Worked Nginx configuration examples

Static and application deployments differ at the final routing decision. Both still share the domain, port 80 listener, size limit, logs, headers, compression, and optional Certbot flow.

Static HTML example

portfolio.example.com

root /var/www/portfolio.example.com/html;
index index.html index.htm;

location / {
    try_files $uri $uri/ =404;
}

Turn on SPA fallback only when a client-side router owns paths such as /dashboard. Plain HTML should return a real 404 for a missing file.

Python API example

api.example.com → 127.0.0.1:8000

location / {
    proxy_pass http://127.0.0.1:8000;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For
                     $proxy_add_x_forwarded_for;
}

The application stays on loopback while Nginx owns public ports 80 and 443. Port-suffixed filenames help distinguish several local processes.

Production settings reference

These defaults avoid speculative tuning. Each one maps directly to generated Nginx syntax or a deployment command, so turning a control off removes its output rather than hiding it in comments.

SettingDefaultGenerated behavior
HTTPSOnCertbot snap, Nginx plugin, redirect, renewal dry run
Request body10 MBclient_max_body_size 10m
Security headersOnnosniff, strict-origin referrer policy, SAMEORIGIN framing
Static cache30 daysAssets cached; HTML excluded; immutable remains opt-in
WebSocketsOn for appsUnique map variable plus Upgrade headers
Rate limitOffOptional per-IP zone, burst, nodelay, and HTTP 429
Proxy bufferingOnCan be disabled for SSE or streamed responses

Why HTTPS is generated as step 4, not inside the first file

A copied TLS block often points at /etc/letsencrypt/live/domain/ before that directory exists. Nginx then fails its syntax test, so Certbot cannot use the Nginx plugin cleanly. This generator installs a valid HTTP server first, runs nginx -t, reloads, and only then asks Certbot to obtain the certificate and edit the working server.

WebSocket map and rate-limit limit_req_zone directives are also placed before the server block because both belong to the http context. Ubuntu and Debian include sites-enabled/* inside that context. The officialNginx WebSocket guidedocuments the explicit Upgrade and Connection forwarding used here.

Certbot’s official instructions recommend its snap package and a renew --dry-run test. The generated step follows that sequence; review the currentCertbot Nginx instructionswhen your server is not Ubuntu or Debian.

Runs 100% in your browser

Your domain, directory, application port, upstream address, and Certbot email never leave your device. The generator uses browser JavaScript for validation, text generation, copy actions, and downloads. Preferences are stored only in local browser storage. I tested both modes, www and apex certificate flags, Node.js port 3000, Python port 8000, port-suffixed filenames, SPA fallback, WebSocket maps, rate-limit zones, immutable cache header inheritance, and the skipped-HTTPS path.

Frequently asked questions

What does this Nginx config generator create?

It creates one Ubuntu/Debian sites-available configuration plus four ordered command blocks: install and prepare, write and enable, test and reload, and optional Certbot HTTPS. The output is a complete server block, not an isolated location snippet.

Can it configure both plain HTML and a single-page app?

Yes. Static mode serves files from your selected root. Plain HTML uses try_files with a 404 fallback, while the optional SPA setting sends missing routes to /index.html. Asset caching excludes HTML so a new release is not hidden behind a long browser cache.

How does it configure a Node.js or Python application?

App/API mode proxies the public domain to a private host and port, defaulting to 127.0.0.1:3000 for Node.js or 127.0.0.1:8000 for Python. It forwards Host, client IP, scheme, and port headers, and can add WebSocket upgrades, rate limiting, custom timeouts, and streaming-safe buffering controls.

Does the generated Nginx file include HTTPS certificates?

It intentionally starts with a valid HTTP server block. Step 4 then uses Certbot with the Nginx plugin to request certificates, edit the server, redirect HTTP to HTTPS, and test renewal. This order lets nginx -t pass before any certificate files exist.

Why append the application port to the config filename?

The option creates a distinct name such as example.com_5000. It is useful when one server hosts several processes or when staging and production use related domains. The server_name remains the domain; only the sites-available filename and dedicated log names receive the port.

Are my domains, paths, ports, or email uploaded?

No. Generation, validation, downloads, and preference storage all run in your browser. Settings are kept in local browser storage so they return on the next visit. Clearing this site’s browser data or pressing Reset removes the saved preferences.

Should I still run nginx -t before reloading?

Always. The generated step runs sudo nginx -t before sudo systemctl reload nginx. Your server may have other enabled files, modules, or package-specific defaults that this browser tool cannot inspect, so the full installed configuration still needs Nginx’s own syntax test.

Related developer and deployment tools

Last updated: July 11, 2026 · Runs 100% in your browser — no uploads, nothing leaves your device.

Need a different tool?

Browse all 90 browser-based tools (90 currently marked free), or tell us what useful utility we should build next.

Browse all tools