nginx

Configure nginx reverse-proxy vhosts with certbot TLS and validate before reload.

8|1|Updated Jan 21, 2024
One-click install
npx skills add https://github.com/azigler/dotfiles --skill nginx-azigler
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: nginx
Source: https://github.com/azigler/dotfiles/tree/main/agents/skills/nginx
Command: npx skills add https://github.com/azigler/dotfiles --skill nginx-azigler

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps you run one reliable nginx edge that hosts many project vhosts while correctly handling TLS via certbot, reducing the risk of broken sites from bad config reloads or unsafe edits.

Core Features & Use Cases

  • Multi-project vhost layout: Organizes /etc/nginx/ with sites-available/ as source-of-truth and sites-enabled/ via symlinks for active hosts.
  • Operational safety for changes: Enforces a validate-then-apply workflow (nginx -t before any reload) to prevent taking the edge down.
  • TLS via certbot with correct update patterns: Uses certbot for listen 443 and renewals while warning against overwriting certbot-managed live files from repo templates.
  • Trailing-slash correctness: Prevents subtle 404s by requiring redirect companion rules for every browsable /name/ location.
  • Common vhost workflows: Adds vhosts, issues/updates certs, reloads safely, tests config and logs, and removes projects cleanly.

Quick Start

Install a new vhost config into /etc/nginx/sites-available/, symlink it into /etc/nginx/sites-enabled/, then run nginx validation and reload to apply the change.

Frequently Asked Questions about nginx

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I safely add a new nginx reverse-proxy vhost without breaking existing sites?

To safely add an nginx reverse-proxy vhost, place the configuration in sites-available, create a symlink in sites-enabled, and run nginx -t before reloading. This validate-then-apply workflow prevents bad configuration reloads from taking down production edges.

Why do I get 404 errors after adding a trailing slash to my nginx location block?

Trailing-slash 404 errors in nginx location blocks occur when redirect companion rules are missing for browsable /name/ locations. You must configure matching redirect rules for every trailing-slash directory to prevent subtle 404 errors during routing.

How does certbot manage TLS lifecycles for nginx vhosts during deployment?

Certbot manages TLS lifecycles for nginx vhosts by handling listen 443 configurations and automated renewals. You must apply surgical edits to HTTPS blocks rather than overwriting certbot-managed live files from repository templates to keep TLS stable.

What is the best way to structure nginx configuration for multiple project vhosts on one server?

The best way to structure multiple nginx project vhosts is using sites-available as the source-of-truth and sites-enabled via symlinks for active hosts. This symlink discipline keeps multi-project layouts organized and allows safe project removal.

Can I overwrite certbot-managed HTTPS blocks when deploying nginx config templates from a repo?

You cannot overwrite certbot-managed HTTPS blocks when deploying nginx config templates from a repo. Overwriting live certbot files breaks TLS, so you must apply surgical edits to existing HTTPS configurations instead of replacing them entirely.

Do I need to run nginx -t before every configuration reload?

You need to run nginx -t before every configuration reload to enforce operational safety. This validation step checks your syntax and configuration integrity, preventing bad reloads from taking your production reverse-proxy edge down.