Before the tutorial starts, let me explain the underlying logic—otherwise you'll follow the steps, finish, and forget everything within a week.
When a browser requests a URL, the HTTP request includes a Host header carrying the domain name. Nginx reads that header and matches it against its config to decide where to route the traffic. So on one server, one IP, as long as Nginx has separate rules for each domain, each one can point to a completely different folder. That's virtual hosting, stripped down to its essence.
Once that clicks, everything below is just writing that logic into config files.
Environment setup
Ubuntu 22.04 or 24.04 is the recommendation—stable, well-documented, easy to find help for. Install Nginx first:
sudo apt update
sudo apt install nginx
Nginx starts automatically after installation. Hit the server IP in a browser—if you see the default welcome page, you're good.
Step 1: Give each site its own directory
A lot of beginners skip this and regret it later. One site, one directory. It's the foundation for migrating, backing up, and debugging things cleanly down the road.
Say you have two domains, site1.com and site2.com:
sudo mkdir -p /var/www/site1
sudo mkdir -p /var/www/site2
Drop some test pages in so you can verify the config actually works later:
echo "site1 works" | sudo tee /var/www/site1/index.html
echo "site2 works" | sudo tee /var/www/site2/index.html
Step 2: Write the Nginx config files
One config file per domain, all living in /etc/nginx/sites-available/.
Config for site1.com:
sudo nano /etc/nginx/sites-available/site1
server {
listen 80;
server_name site1.com www.site1.com;
root /var/www/site1;
index index.html;
}
Same thing for site2.com:
sudo nano /etc/nginx/sites-available/site2
server {
listen 80;
server_name site2.com www.site2.com;
root /var/www/site2;
index index.html;
}
Step 3: Enable the sites and reload Nginx
Nginx's system: configs live in sites-available, but they only activate when symlinked into sites-enabled.
sudo ln -s /etc/nginx/sites-available/site1 /etc/nginx/sites-enabled/
sudo ln -s /etc/nginx/sites-available/site2 /etc/nginx/sites-enabled/
Before reloading, test for syntax errors—don't skip this:
sudo nginx -t
You want to see syntax is ok and test is successful. If there's an error, the output will tell you which line. Usually a missing semicolon or a mismatched bracket.
sudo systemctl reload nginx
Step 4: Point DNS at your server IP
Head to your DNS provider (Cloudflare, Namecheap, wherever) and add A records for each domain:
site1.com -> your VPS IP
www.site1.com -> your VPS IP
site2.com -> your VPS IP
www.site2.com -> your VPS IP
Propagation time varies—anywhere from a few minutes to a few hours. Cloudflare tends to be fast, usually done within minutes. Once it's live, visiting either domain in a browser should show the test pages you created earlier.
Step 5: HTTPS—not optional
HTTP sites get flagged in Google search results and trigger browser warnings. There's no reason to skip SSL in 2026, especially when it's completely free. Certbot handles everything automatically:
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx
It'll detect your configured domains, ask which ones you want HTTPS on, then request Let's Encrypt certificates and update the Nginx config on its own. Certificates auto-renew every 90 days—nothing to manage.
Running multiple WordPress sites
Static pages are simple enough, but if you're hosting multiple WordPress installs, the structure is the same—separate directory, separate database, separate Nginx config per site. Don't share databases between sites. One problem in one site shouldn't cascade into others, and shared databases make migration a nightmare.
Create a database for each site separately:
mysql -u root -p
CREATE DATABASE site1_db;
CREATE USER 'site1_user'@'localhost' IDENTIFIED BY 'your_password';
GRANT ALL PRIVILEGES ON site1_db.* TO 'site1_user'@'localhost';
FLUSH PRIVILEGES;
Repeat for site2 with a different database name and username.
How many sites can one VPS actually handle?
Traffic determines the limit, not some config ceiling. On a 2-core 4GB machine, rough estimates:
Pure static HTML—ten, twenty sites, no problem. Memory consumption is nearly zero. WordPress small-to-medium sites—three to eight is a common sweet spot. Beyond that, object caching (Redis) or a page cache plugin becomes worth setting up to take pressure off PHP. High-concurrency e-commerce or heavy dynamic query sites—even one of those needs careful traffic planning.
Personally ran four WordPress sites simultaneously on a 2-core 4GB machine. Day-to-day traffic was fine, but when multiple crawlers hit at the same time, memory pushed above 80%. At that point it's either upgrade RAM or tighten the caching config—one or the other.
Common beginner mistakes worth mentioning
Sharing one directory across multiple sites is the most frequent error. Files get mixed together and untangling it later is miserable. Not separating databases is the second—debugging problems across intermingled data is twice as hard. Skipping HTTPS before launch hurts both SEO and user experience, and it's free, so there's no excuse.
One more thing that deserves its own mention: backups. Multiple sites on one server means one bad command can affect all of them simultaneously. Build a regular backup habit, or use the automatic backup features in a panel like aaPanel or HestiaCP. Much cheaper than recovering from a disaster.
Prefer a GUI? Panels work fine too
The steps above aren't complicated if you have basic Linux familiarity—but if you just want things running quickly, aaPanel or HestiaCP offer graphical interfaces for all of this: domain binding, one-click SSL, database management, all through a browser. The tradeoff is the panel itself consumes some memory. On very small machines (512MB RAM), it can feel a bit cramped.
Once everything's configured, day-to-day maintenance is genuinely low-effort. Nginx configs are one file per site—clean and easy to edit. Certificates renew themselves. Adding a new site means walking through the same steps above. Running multiple sites on one VPS is one of the most cost-effective hosting setups available—no reason to spin up a separate machine for every domain.