Separate config files per site in Nginx - Step-by-Step Execution

Process Flow - Separate config files per site

Create separate config files

↓

Place files in sites-available

↓

Link files to sites-enabled

↓

Reload nginx to apply

↓

Requests routed to correct site config

This flow shows how nginx uses separate config files for each site by placing them in sites-available, linking to sites-enabled, and reloading nginx to apply.

Execution Sample

Nginx

sudo nano /etc/nginx/sites-available/site1.conf
sudo ln -s /etc/nginx/sites-available/site1.conf /etc/nginx/sites-enabled/site1.conf
sudo nginx -t
sudo systemctl reload nginx

Create a config file for site1, link it to enable, test config, and reload nginx to apply changes.

Process Table

Step	Action	Command/Config	Result/Output
1	Create site1 config file	sudo nano /etc/nginx/sites-available/site1.conf	File created with server block for site1
2	Enable site1 config	sudo ln -s /etc/nginx/sites-available/site1.conf /etc/nginx/sites-enabled/site1.conf	Symbolic link created
3	Test nginx config	sudo nginx -t	nginx: configuration file /etc/nginx/nginx.conf test is successful
4	Reload nginx	sudo systemctl reload nginx	nginx reloads with new site1 config active
5	Request to site1 domain	curl http://site1.example.com	Response served by site1 config

💡 After reload, nginx uses separate config files per site to route requests correctly.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4
sites-available/site1.conf	does not exist	created with server block	unchanged	unchanged	unchanged
sites-enabled/site1.conf	does not exist	does not exist	symbolic link created	unchanged	unchanged
nginx config status	unknown	unknown	unknown	test successful	reloaded with new config

Key Moments - 3 Insights

Why do we create config files in sites-available and not directly in sites-enabled?

sites-available holds all site configs safely; sites-enabled holds only active sites via links. This separation helps manage which sites are active without deleting configs. See execution_table steps 1 and 2.

What happens if nginx config test fails after adding a new site config?

nginx -t will show errors and prevent reload. This stops nginx from applying broken configs. See execution_table step 3 where test is successful; if it failed, reload would not happen.

Why do we need to reload nginx after adding or changing site configs?

Reload tells nginx to re-read config files and apply changes without downtime. Without reload, new configs are ignored. See execution_table step 4.

Visual Quiz - 3 Questions

Look at the execution table, what is the result of running 'nginx -t' at step 3?

A nginx: configuration file test is successful

B nginx reloads with new site1 config active

C Symbolic link created

D File created with server block for site1

💡 Hint

Check the 'Result/Output' column at step 3 in the execution_table.

At which step does the symbolic link get created to enable the site config?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Look at the 'Action' and 'Command/Config' columns in the execution_table for when 'ln -s' is run.

If you skip the reload step, what will happen when you request the site domain?

A Request will be served by the new site config

B Request will fail with error

C Request will be served by old config, ignoring new site

D nginx will automatically reload

💡 Hint

Refer to execution_table step 4 and 5 about reload and request handling.

Concept Snapshot

Separate config files per site in nginx:
- Place each site config in /etc/nginx/sites-available/
- Enable by linking to /etc/nginx/sites-enabled/
- Test config with 'nginx -t'
- Reload nginx to apply changes
- This keeps configs organized and active sites controlled

Full Transcript

This lesson shows how to manage multiple websites on nginx by using separate configuration files for each site. You create a config file for each site in the sites-available directory. Then you enable a site by creating a symbolic link to that file in sites-enabled. Before applying changes, you test the configuration with 'nginx -t' to avoid errors. Finally, you reload nginx to apply the new or changed site configurations. This method keeps your site configs organized and lets you easily enable or disable sites without deleting files.