What We Built (High-Level)
This lab demonstrates how a single Linux server can host multiple independent websites using a reverse proxy, virtual hosts, and separate databases — a common real-world pattern for multi-tenant hosting.
Goal
Two sites, one server
Isolation
Separate MySQL DBs
Routing
Reverse proxy by hostname
Clickable Sections
Click a section to see what we did, why we did it, and what to show as proof.
1) DNS + Subdomain (lab.jakegunn.com)
Why: DNS tells the internet where lab.jakegunn.com lives. Without it, browsers
can’t reach the server and Let’s Encrypt can’t validate certificates.
- Verified DNS propagation using dig +short lab.jakegunn.com
- Confirmed the subdomain resolves to the same server IP as the primary site
2) Multi-Tenant Hosting (Two sites on one server)
Why: Multi-tenant hosting is common for labs, dev environments, and small hosting setups. One server runs multiple websites by matching hostnames in Apache VirtualHosts.
- Primary site served from /var/www/jakegunn.com/html
- Lab site served from /var/www/lab.jakegunn.com/html
- Both websites are reachable publicly with different content
3) Database Isolation (Separate MySQL DB per site)
Why: Each site has its own database to keep content/users/settings separate and reduce blast radius.
- Created a dedicated DB + user for lab WordPress
- Configured
wp-config.phpfor the lab site to use the lab database - Verified
homeandsiteurlmatch HTTPS for the lab domain
4) Reverse Proxy (Apache)
Why: Reverse proxies route traffic to internal services without exposing internal ports publicly. Here, Apache accepts HTTPS and forwards requests internally to a backend WordPress site on port 8081.
- Backend bound to port 8081 (internal service)
- Front-end VirtualHost on :443 proxies to 127.0.0.1:8081
- Port 80 redirects to HTTPS for clean browser behavior
5) HTTPS + Certbot
Why: HTTPS encrypts credentials and admin sessions. Certbot automates Let’s Encrypt certificates and renewals so the site stays trusted by browsers.
- Issued and installed SSL certificate for lab.jakegunn.com
- HTTPS enforced for secure admin login
- Certificate auto-renew enabled
6) Troubleshooting Notes (Real-World Problem Solving)
Why this matters: Reverse proxies + WordPress often require fixing protocol detection and redirect loops. This lab included real troubleshooting like you’d do in production.
- Redirect loop: Fixed by ensuring WordPress
home/siteurlmatched HTTPS. - Admin login warnings: Resolved by aligning proxy behavior and WordPress URL settings.
- Validation: Used
curl -ILto trace redirect chains and confirm 200 OK.
7) Proof Checklist (Screenshots / Commands)
Use these as your “receipts” for the lab submission. Screenshot the outputs and the two working websites.
- Cloudflare DNS record showing A → lab points to the server IP (DNS only)
- Screenshot: https://jakegunn.com loads (site A)
- Screenshot: https://lab.jakegunn.com loads (site B)
- Command proof: backend service running on 8081
- Command proof: show databases exist (wordpress + lab_wordpress)
- Command proof: Apache VirtualHosts show both domains mapped
Optional nice touch: Change the lab site title to “Lab Environment – Reverse Proxy Test” to visually prove it’s separate from the main site.