Skip to main content
This module covered the essentials of installing, configuring, and operating NGINX. Below is a concise, actionable recap of what we covered, plus practical recommendations for production use.

​
Installation and package management

  • Prefer your distribution’s package manager (apt, yum/dnf, pacman, etc.) to install, upgrade, and remove NGINX. Package managers handle dependencies and updates, simplifying maintenance.
  • Compile from source only when you need custom modules, patches, or are targeting an unsupported platform.
Use your OS package manager for most installations—it’s safer and easier to maintain than compiling NGINX from source.

​
Platforms and production recommendations

  • Example commands in this course used Ubuntu; installation steps are similar across mainstream Linux distributions.
  • You can test NGINX on Windows or macOS for learning, but run production NGINX on Linux where it is best supported and most commonly deployed.

​
Controlling NGINX processes

NGINX’s master process accepts signals via the nginx -s command for direct control. Common commands:
On systemd-based systems you will most often use higher-level commands such as sudo systemctl restart nginx or sudo systemctl reload nginx. Use nginx -s when you need direct control of the NGINX master process. Quick reference: common signals and systemd equivalents

​
Configuration structure

The main configuration file is nginx.conf. Key sections to understand:
  • Global directives: user, worker_processes, error_log, etc.
  • events block: connection-related settings (e.g., worker_connections).
  • http block: global HTTP settings, MIME types, gzip, proxy settings, etc.
  • server blocks: virtual hosts inside the http block; each server handles one or more hostnames/ports.
Quick file locations (typical on Debian/Ubuntu): Use separate server blocks to host multiple sites on a single NGINX instance.

​
Serving static files and virtual hosts

  • NGINX is highly efficient at serving static content (HTML, CSS, JS, images).
  • Host multiple sites by creating separate server blocks and setting server_name for each domain.
  • If server_name is omitted or does not match, NGINX uses the first matching server block for that listen socket. On distributions using sites-enabled, the order of included files can determine which server becomes the default — this can cause unexpected site selection if not managed explicitly.

​
Customizing the default page

To replace the default NGINX welcome page, edit the document root (commonly /var/www/html/index.html) and add your own HTML (a simple “Hello World” page is a common first step). Ensure file permissions and ownership allow the NGINX worker processes to read the files.

​
Firewall and port management

  • Enable and configure the host firewall (UFW, firewalld, nftables) on Linux servers. Only open the IPs and ports you expect to use.
  • Ports 80 (HTTP) and 443 (HTTPS) are typically open for public websites. For internal testing, restrict access to known IPs.
  • Cloud providers (AWS, GCP, Azure) have separate network-level firewalls/security groups—make sure these rules line up with your host firewall.
Do not forget to synchronize cloud provider security groups with your server’s firewall rules. A mismatch can leave your server unreachable or exposed.
A presentation slide titled "Summary" with a blue left panel. It lists three numbered points about Nginx: serving static sites and hosting multiple sites with server blocks, customizing Nginx's default page, and the importance of firewall and ports management.

​
Further reading and references

Thanks again for working through this module. You’ve earned a break—go grab a cup of coffee.

Watch Video

Practice Lab