Does the Nginx Config Generator call any external API?

No. Every directive is assembled locally in the browser from your validated inputs, so the domain, document root and cache duration never travel to a remote service.

Why does the generator not produce HTTPS configuration?

Certificate paths, renewal tooling, supported protocols, redirect topology and HSTS policy all depend on deployment-specific evidence, so inventing TLS configuration would be unsafe.

When should SPA fallback be enabled?

Only when client-side routing should receive unknown application paths. Ordinary content sites should preserve a real 404 instead of returning the home shell with status 200.

Is nginx -t enough to prove the new block works?

No. It validates syntax and module references, but you still need to test permissions, DNS resolution, representative request paths, cache behavior and gzip responses before any reload.

Nginx Config Generator API Alternative: No Server Calls

An nginx config generator API alternative is a tool that produces the same auditable server blocks a hosted API would return, but assembles every directive locally in your browser without sending the domain, document root or cache values to a remote service. The Nginx Config Generator works this way: it validates one exact domain, an absolute POSIX document root, an integer cache duration between 1 and 365 days, and an explicit choice between a static 404 or an SPA fallback that rewrites unknown paths to /index.html. Output stays on the device, which removes rate limits, API keys, network dependencies and the risk that a third party sees the hostname you intend to publish. The result is a narrow HTTP server block listening on IPv4 and IPv6 port 80, ready for review against the installed Nginx modules before it ever reaches /etc/nginx. The deliberate omissions are part of the value: TLS, PHP, FastCGI, reverse proxies, WebSockets, authentication, rate limits, custom errors, MIME include paths, logging and security headers are excluded because each of those decisions depends on deployment evidence the browser cannot see.

What Makes a Browser-Side Generator Different

Hosted Nginx config APIs are useful, but they come with constraints that do not always match the task. A typical generator hosted at a URL accepts your domain and document root, returns a configuration fragment, and stores or logs the request on its infrastructure. That model has tradeoffs worth naming explicitly:

Network dependency. No internet, restricted CI runners, or locked-down laptops cannot reach the API. A browser-side alternative keeps working.
Rate limits and quotas. Free tiers throttle. A local generator has no rate limit because no remote endpoint is involved.
Input exposure. The hostname, root path and cache values travel to a third party. Compliance, NDA or client-policy constraints may forbid this.
Hidden assumptions. Hosted generators often default to TLS, www redirects, security headers and other settings that may not match the deployment evidence you actually have.

The Nginx Config Generator is positioned as an API alternative: every directive is assembled in the browser from your validated inputs and stays on the device. Nothing is uploaded, nothing is logged remotely, and the output is a deliberately narrow HTTP server block you can review against the Nginx core module documentation before it touches the live config.

How the Generator Validates Inputs Locally

Three inputs are required and two are optional. Each is checked before the block is assembled:

Domain. Exactly one server_name, no scheme prefix, no wildcard, no regular expression. Wildcards and regex server names affect virtual-host routing and certificate coverage, so they are rejected rather than guessed at.
Document root. An absolute POSIX path built from bounded safe characters. Semicolons, braces, variables, whitespace and shell-like syntax are rejected so user input cannot smuggle additional directives into the generated block.
Cache duration. An integer between 1 and 365 days for the expires directive on the asset location. Outside that range the input is rejected; arbitrary durations are not supported.
SPA fallback (optional). When enabled, the final try_files argument becomes /index.html so client-side routing receives unknown paths. When disabled, the fallback is an explicit =404 to preserve real missing-resource semantics.
Gzip (optional). When enabled, the standard gzip filter is added, Vary: Accept-Encoding is emitted, and CSS, JavaScript, JSON and SVG appear in gzip_types. HTML is handled by Nginx's default gzip behavior without needing to appear in the list.

The asset location is a separate case-insensitive block that targets a fixed extension list: CSS, JavaScript, common images, icons and WOFF2 fonts. Anything outside that list is served by the main location. The Nginx gzip module documentation is the source of truth for the gzip directives that appear in the output.

Generate a Static-Site Block in Three Reviewed Phases

Enter one domain, one absolute document root, one cache duration, and an explicit fallback choice. Use the exact hostname you intend to publish. Do not include the scheme (no http://). Do not add a www alias, wildcard, or regular expression in the same field. If several names should serve or redirect, plan that behavior outside the generator. The document root must be an absolute POSIX path that already exists on the target server with the right ownership and read permissions; the browser cannot inspect those facts. Pick a cache duration that matches how you actually version your assets: long-lived only when fingerprints or hashes change between deployments. Decide whether the missing-resource behavior is a real 404 (ordinary content site) or /index.html (SPA). Enabling SPA fallback for a content site can hide broken URLs because the home shell is returned with status 200.
Generate the block and review every directive against the installed Nginx modules, deployment paths and cache strategy. The output is one HTTP server block listening on IPv4 and IPv6 port 80 with one server_name, a root, an index, a try_files chain, a bounded asset location with expires and Cache-Control public, and optional gzip lines. Cross-check each line against the Nginx core module documentation. Confirm that the file you are about to write matches the include chain your server expects (sites-available and sites-enabled, conf.d, or a custom path). Confirm that the cache duration makes sense given whether your assets are fingerprinted. Confirm that gzip types align with what your build actually emits.
Back up the active configuration, place the fragment in context, run nginx -t, and test representative requests before reload. Save the current nginx.conf and any included files. Record the include chain so the backup is recoverable. Drop the reviewed file into the right context, then run nginx -t against the full configuration. A passing syntax test does not prove file permissions, DNS, application routing or certificate behavior, so curl a small set of representative paths afterward: the root, a deep static asset, and a client-side route if SPA fallback is enabled. Reload rather than abruptly stopping the service when the platform procedure supports it, and keep a recovery shell open. If nginx -t fails, do not reload. If requests fail after reload, restore the backup and inspect the error log. A careful reload walkthrough is worth keeping in muscle memory before the first real production cutover.

What the Generator Excludes by Design

The output is a static-site fragment, not a production baseline for every application. The following are deliberately omitted because each one depends on deployment evidence the browser cannot inspect:

TLS, HTTPS, certificate paths, protocols, HSTS. Correct HTTPS configuration depends on certificate storage, renewal tooling, supported protocol versions, redirect topology, CDN or proxy placement and HSTS policy. Inventing those values would create false confidence.
Wildcard, alternate www, and regex server names. These change virtual-host routing and certificate coverage, so they are rejected at the input stage rather than emitted.
PHP, FastCGI, reverse proxying, WebSockets, uploads. Application backends require backend topology, socket paths or upstream definitions that the browser does not know.
Authentication, rate limits, custom errors, MIME include paths, logging, security headers. Each of these interacts with the platform, application and threat model in deployment-specific ways.

For HTTPS, configure certificates and redirects through the hosting platform or a reviewed server procedure, then test HTTP-to-HTTPS behavior separately. For application backends, add only directives required by the actual architecture and the official module documentation.

Test the Block Before Any Production Reload

nginx -t validates syntax and module references, but it does not prove that the site works. The minimum set of post-test checks before any reload should cover:

Permissions. The Nginx worker user must be able to read the document root and traverse every parent directory. A syntax-passing block can still serve 403s on every request if ownership is wrong.
DNS. A passing test against localhost or a test hostname does not prove the public domain resolves to the right server.
Representative paths. A GET on the root, a GET on a deep static asset, and (if SPA fallback is enabled) a GET on a client-side route that does not exist as a file.
Cache behavior. An asset response should include the chosen expires duration and Cache-Control public. A fingerprinted asset should be safe to mark long-lived; an unfingerprinted asset should not.
Compression behavior. When gzip is enabled, a request with Accept-Encoding: gzip should receive a gzipped response with the expected Vary header.

Permanent cache and routing mistakes can affect visitors even when Nginx remains online, so the reload step is the last thing, not the first, in the workflow.

When a Browser-Side Generator Is the Wrong Tool

The smallest reviewed config that matches current deployment evidence is the most maintainable result. When the deployment evidence is somewhere other than a plain /etc/nginx server block, a different surface is the right one. The table below summarizes where the generator fits and where it does not.

Scenario	Generator Fit	Reason
Single static origin behind Nginx	Yes	Output matches the deployment evidence directly
Single-page app with client-side routing	Yes	SPA fallback delivers unknown paths to /index.html
Static origin behind a CDN	Partial	Origin block stays simple; edge config handles TLS and routing
PHP, FastCGI, or WordPress	No	Backend topology and rewrites are out of scope
Kubernetes ingress	No	The configuration surface is an Ingress resource
Multi-host virtual hosting with redirects	No	Wildcards and www redirects are deliberately excluded
TLS-only production	No	HTTPS depends on certificate paths and proxy topology

If your situation appears in the No rows above, the right move is to keep the generator for what it does well, a single static or SPA origin, and let the hosting platform, container image, ingress controller, or CDN handle the parts it deliberately excludes.

From Inputs to Auditable Config

The Nginx Config Generator approach is narrow on purpose. It validates a few well-bounded inputs, emits a small block, and refuses to invent the parts that depend on deployment evidence. That is what makes it a workable nginx config generator API alternative: the same auditable artifact you would request from a hosted API, with no remote call, no rate limit, and no third-party log of the hostname you intend to publish. Treat the generated block as the smallest reviewed config that matches what you actually know about the target server, then add the remaining directives through the platform or a separate reviewed procedure once that evidence exists.