What Is an Application Server? Types & Examples

This is a working reference on application servers — the same material our application server support engineers use when assessing a stack. It covers what an application server does, how it differs from a web server, the common servers for each language runtime, the standard architecture they sit in, and the operational concerns that come with running one in production.

What is an application server

An application server is the software layer that executes application code. When a request arrives, the application server runs the program that handles it — evaluating business logic, querying databases, calling other services — and produces a response that did not exist before the request came in. This distinguishes it from a web server, whose core job is delivering content that already exists on disk.

The term originated with the Java EE era, where products such as WildFly and WebLogic provided a full container: deployment, transactions, connection pooling, messaging, and security in one runtime. In current usage the term is broader. Any process that hosts application code behind an HTTP interface — Tomcat running a Java WAR, Gunicorn running a Python WSGI app, PHP-FPM executing PHP scripts, a Node.js process, or Kestrel hosting an ASP.NET Core application — functions as an application server.

Web server vs. application server

The difference is what each layer does with a request. A web server serves static content (HTML files, images, CSS, JavaScript bundles) and forwards, or proxies, dynamic requests elsewhere. An application server executes code to generate the response.

The boundary has blurred. nginx and Apache httpd can execute code through modules and FastCGI; Tomcat, Node.js, and Kestrel can serve static files and speak HTTP directly to clients. In practice most production deployments still keep both layers, because a dedicated web server handles TLS, static assets, buffering, and slow clients more efficiently than a code-executing runtime does. The nginx proxy module documentation describes the reverse-proxy pattern that connects the two.

Application server examples by stack

Each language ecosystem has settled on a small set of standard servers.

Fuller treatments of two of these are in our Apache Tomcat guide and our IIS overview.

Typical architecture: reverse proxy, application server, database

The standard three-part layout: a reverse proxy (nginx, Apache httpd, or IIS) listens on ports 80 and 443, terminates TLS, serves static assets directly, and forwards dynamic requests over an internal port or Unix socket to the application server; the application server (Tomcat on 8080, Kestrel on 5000, Gunicorn workers on a socket) executes the request and reads or writes data through a connection pool to the database server, which sits on a private network segment reachable only from the application tier. Responses flow back the same path, with the proxy handling compression and buffering on the way out. Load-balanced deployments repeat the middle tier — one proxy distributing across several identical application server instances.

What application servers manage

• Threads and processes. Tomcat maintains a request thread pool; Gunicorn and PHP-FPM fork worker processes; Node.js runs an event loop with optional clustering. Sizing these against CPU count and workload is the main tuning lever.
• Connection pooling. Database connections are expensive to open, so the server (or its framework) keeps a pool and hands connections to requests. Pool exhaustion is a common cause of stalled applications.
• Session state. In-memory sessions, sticky sessions at the load balancer, or externalized sessions in Redis or a database — the choice determines whether instances can be added and removed freely.
• Application lifecycle. Deployment, startup and shutdown hooks, health endpoints, and — in Java containers — hot deployment of application archives.

Deployment models

On bare metal or VMs, the application server runs as a system service (systemd unit, Windows service) with the reverse proxy on the same host or a separate tier; this remains the norm for long-lived line-of-business systems. In containers, each application server instance runs as a container image with an orchestrator handling placement, restarts, and scaling — the server software is the same, but lifecycle management moves from the OS service manager to Kubernetes or an equivalent. The operational concerns below apply to both models; containers change who restarts the process, not whether it needs restarting.

Operations concerns

• Restarts on deploy. Most stacks require a process restart to pick up new code; the deploy pipeline must sequence this against live traffic.
• Memory growth and leaks. Long-running JVM, Node, and Python processes accumulate heap over time; monitoring resident memory and setting restart thresholds prevents slow degradation.
• Log management. Access logs, application logs, and garbage-collection or worker logs each need rotation and shipping to a central store before disks fill.
• Zero-downtime patterns. Rolling restarts behind a load balancer, Gunicorn's graceful worker reload, PM2's cluster reload, and blue-green deployment all exist to swap code without dropping in-flight requests.
• Patching. The server software itself (Tomcat releases, Node LTS updates, PHP-FPM versions) has its own security lifecycle, separate from the application code it runs.

FAQ

What is the difference between a web server and an application server?

A web server serves static content and proxies requests; an application server executes code to generate responses. nginx, Apache httpd, and IIS are web servers; Tomcat, Kestrel, Gunicorn, PHP-FPM, and Node.js are application servers. Most production sites run both, with the web server in front.

Is nginx an application server?

No. nginx serves static files and reverse-proxies dynamic requests to an application server. It can invoke code through FastCGI, but it does not host application runtimes itself.

Is Node.js an application server?

Yes, in function. The Node.js runtime includes an HTTP server, and a Node process running Express or Fastify performs the application-server role. Production setups add a process manager such as PM2 and usually an nginx reverse proxy in front.

Do I always need a separate web server in front?

Not always. Kestrel, Tomcat, and Node can face the internet directly, and some cloud load balancers replace the proxy layer. A separate web server is still standard when you need efficient static file serving, TLS management, request buffering, or multiple applications behind one IP.