Skip to main content
Back to Dev generators

Dev

Dummy Nginx Config Generator

Used by developers, writers, and creators worldwide.

A dummy nginx config generator saves the hour you'd otherwise spend cross-referencing documentation every time you spin up a new server. One wrong semicolon or a mismatched SSL path is enough to take a site down, so starting from a known-good template beats writing from scratch. Enter your domain, pick your server type — static, reverse proxy, Node.js, or PHP — and choose whether to include SSL. The output follows real conventions: SSL paths match certbot defaults, proxy headers include X-Real-IP and X-Forwarded-For, and PHP configs wire up to the standard php-fpm socket. Copy it straight into /etc/nginx/sites-available and you're done.

Loading usage…

Free forever — no account required

How to use

  1. Choose your options above
  2. Click Generate
  3. Copy your result

Detailed instructions

  1. Enter your actual domain name in the Domain Name field, for example app.yourdomain.com.
  2. Set Include SSL to 'yes' if your server already has a Let's Encrypt certificate, or 'no' to generate a plain HTTP config first.
  3. Select your Server Type: choose reverse-proxy for Node/Python apps, static for HTML sites, or php for PHP-FPM applications.
  4. Click Generate and review the output, noting the proxy_pass port or root directory and adjusting them to match your environment.
  5. Copy the config, save it to /etc/nginx/sites-available/yourdomain.conf, symlink it, run nginx -t, then reload Nginx.

Use Cases

  • •Generating a reverse proxy config for a Node.js app on port 3000 before running nginx -t
  • •Scaffolding an SSL-enabled static site block for a marketing landing page deploying to a fresh Ubuntu VPS
  • •Creating Nginx config fixtures for Ansible roles that manage sites-available in CI pipelines
  • •Building a PHP-FPM config baseline for WordPress or Laravel behind Nginx in a docker-compose stack
  • •Giving junior engineers a correctly structured reference config to study during onboarding

Tips

  • →Generate with SSL disabled first, run certbot --nginx, then regenerate with SSL enabled to compare against what certbot wrote.
  • →For Node.js apps using clustering or PM2, change the proxy_pass value to a named upstream block with multiple server lines for load balancing.
  • →If you serve multiple subdomains on one VPS, generate a separate config for each — do not stack multiple server_name values in one block until you understand precedence rules.
  • →The static site config sets root to /var/www/yourdomain — create that directory and drop an index.html in it to verify the config works before deploying real files.
  • →On PHP configs, confirm your installed php-fpm socket path with: ls /run/php/ — it may differ from the generated path if you have multiple PHP versions installed.
  • →After editing the config, always run nginx -t before reloading — a syntax error on a reload will leave the old config running, masking your changes silently.

FAQ

how do I activate a generated nginx config on Ubuntu without breaking the site

Save the file to /etc/nginx/sites-available/yourdomain.conf, then symlink it with sudo ln -s /etc/nginx/sites-available/yourdomain.conf /etc/nginx/sites-enabled/. Always run nginx -t before reloading — it validates syntax and catches errors before they take the server offline. If the test passes, apply with sudo systemctl reload nginx.

does the ssl config match what certbot actually generates

Yes. The certificate paths use certbot's default output at /etc/letsencrypt/live/yourdomain/, so the config works without edits if you ran certbot with default flags. Run certbot first to create the actual certificate files, then drop in the generated config. If you used a custom output directory, update the ssl_certificate and ssl_certificate_key lines to match.

can I use the reverse proxy config with docker-compose instead of localhost

Yes, but change the proxy_pass host from 127.0.0.1 to your backend's service name as defined in docker-compose.yml — containers resolve each other by service name, not localhost. Mount the generated config into /etc/nginx/conf.d/ via a volume or Dockerfile COPY, then restart the Nginx container to pick it up.