Managing Multiple Applications
Introduction
Welcome back to "Getting Started with NGINX Web Server"! You're now at lesson three and making excellent progress. In the first lesson, we learned how to serve static files. In the second, we configured NGINX as a reverse proxy to forward API requests to a backend. Now we're ready to tackle a common real-world scenario: hosting multiple applications through a single NGINX instance.
Many organizations run several web applications on the same server, each with its own domain or subdomain. Rather than launching separate NGINX instances for each application, we can configure one NGINX server to route requests intelligently based on the requested hostname. This approach is called name-based virtual hosting, and it's one of NGINX's most practical features.
In this lesson, we'll configure two distinct applications served from the same NGINX instance, each with its own static files and backend API. We'll see how NGINX can differentiate between requests using the server_name directive, allowing us to manage multiple services efficiently from a unified configuration.
The Challenge of Multiple Applications
Consider a scenario where we're running two separate projects: perhaps a customer-facing portal and an internal admin dashboard. Each application has its own static files, its own backend API, and ideally its own domain name, like portal.company.com and admin.company.com.
Without virtual hosting, we'd face some difficult choices. We could run each application on a different port (one on 3000, another on 3001), but that creates awkward URLs and complicates firewall rules. We could run multiple NGINX instances, but that wastes resources and becomes harder to manage. Or we could merge both applications into one codebase, sacrificing clean separation.
Virtual hosting solves this elegantly: one NGINX instance listens on a single port but routes requests to different applications based on the requested hostname. This keeps applications isolated while presenting them through standard HTTP/HTTPS ports.
Understanding Virtual Hosts
A virtual host is a server configuration that responds to requests for a specific domain name. When a client makes an HTTP request, it includes a Host header indicating which domain it's trying to reach. NGINX reads this header and matches it against the server_name directives in its configuration.
For example, when a browser requests http://app1.local/, it sends:
NGINX examines this Host header and selects the server block with server_name app1.local. This mechanism allows NGINX to host dozens or even hundreds of applications on a single instance, each responding to different domain names.
For our lesson, we'll use two local domain names: app1.local and app2.local. These represent two independent applications that we want to serve from the same NGINX server.
