Apache vs Tomcat: Differences & When to Use Each

Our Apache and Tomcat support team gets this comparison question regularly, and the confusion is understandable: both projects come from the Apache Software Foundation and both carry the Apache name. They are different tools for different jobs. Apache HTTP Server (httpd) is a general-purpose web server written in C — it serves static files, hosts PHP sites, and acts as a reverse proxy. Apache Tomcat is a Java servlet container — it runs Java web applications and implements the Jakarta Servlet, JSP, and WebSocket specifications. If the application is written in Java, the choice is Tomcat; if it is anything else, the choice is httpd or another general-purpose server. Many production stacks run both, with httpd in front proxying to Tomcat behind it.

Apache vs Tomcat: comparison table

What Apache HTTP Server is for

httpd is the general-purpose layer of a web stack. Its standard roles:

• Static sites and files. HTML, images, JavaScript bundles, downloads — served directly from disk with OS-level optimizations.
• PHP applications. WordPress, Laravel, and similar stacks run under httpd via mod_php or, more commonly now, PHP-FPM over FastCGI.
• Reverse proxy and load balancer. mod_proxy forwards requests to backend application servers — Tomcat included — and mod_proxy_balancer distributes load across several of them.
• Virtual hosting at scale. One httpd instance can serve hundreds of sites through name-based virtual hosts, each with its own document root, TLS certificate, and rewrite rules.

The current stable branch is 2.4.x. It cannot run a Java application by itself — a WAR file means Tomcat or another servlet container is required.

What Tomcat is for

Tomcat exists to run Java web applications. It implements the Jakarta Servlet, JSP, Expression Language, and WebSocket specifications; current supported branches are 9.0.x (Servlet 4.0, the last Java EE line), 10.1.x (Servlet 6.0), and 11.0.x (Servlet 6.1), per the project's version guidance. Deployment is typically a WAR file dropped into the webapps directory or an exploded application directory.

One note on modern Java deployment: Spring Boot embeds Tomcat by default for servlet applications — the standard web starter packages Tomcat inside the application JAR, listening on port 8080. Teams running Spring Boot are running Tomcat whether they administer a standalone instance or not; the difference is that upgrades arrive through the application's dependency versions rather than a server package. Branch lifecycles and end-of-life dates for standalone instances are covered in our Tomcat versions guide.

Running Apache and Tomcat together

The classic production pattern puts httpd in front of Tomcat: httpd terminates TLS, serves static assets, handles virtual hosting and rewrites, and proxies application requests to Tomcat. There are two connection methods:

• mod_proxy_http — plain HTTP from httpd to Tomcat's port 8080 connector. Simple to configure, easy to debug with standard HTTP tooling, and the generally preferred choice for new setups.
• AJP (mod_proxy_ajp or mod_jk) — a binary protocol to Tomcat's port 8009 connector. AJP carries more of Tomcat's internal request state across the wire, which is also why it needs stricter handling: since the Ghostcat vulnerability (CVE-2020-1938), Tomcat ships with the AJP connector disabled in the default server.xml, bound to localhost when enabled, and — per the AJP connector documentation — refusing to start unless a shared secret is configured (the secretRequired attribute defaults to true). The docs explicitly flag AJP as requiring additional security consideration because it allows greater direct manipulation of Tomcat's internals than the HTTP connectors.

Unless an existing deployment already depends on AJP-specific behavior, proxying over HTTP is the lower-risk option. Either way, the front-end/back-end split lets each server do the work it is built for. Setup steps for the combined stack are in our Apache Tomcat guide.

When you only need one

• Only httpd: static sites, PHP applications, or a reverse proxy in front of non-Java backends. No Java means no reason to run a JVM.
• Only Tomcat: a single Java application on an internal network, or behind a cloud load balancer that already terminates TLS. Tomcat's own HTTP connector is production-capable on its own.
• Both: Java applications that share a server with static content or PHP sites, need httpd-style rewrites and virtual hosting, or sit behind one TLS termination point serving mixed backends.
• Neither alone decides it: Spring Boot deployments usually skip standalone Tomcat entirely and put a reverse proxy (httpd or nginx) or a load balancer in front of the embedded server.

Where nginx fits

nginx is the third common option in this comparison. It occupies the same role as httpd — general-purpose web server and reverse proxy — with an event-driven architecture and a different configuration syntax, and it is a frequent choice as the front end for Tomcat via proxy_pass. nginx does not run Java applications either; choosing nginx over httpd changes the proxy layer, not the need for a servlet container. Teams already standardized on one front end rarely gain much by switching for a Tomcat deployment.

Performance: the honest framing

Generic benchmark numbers for httpd versus Tomcat are mostly meaningless because the two servers do different work. For static files, httpd (or nginx) is the right tool: requests are served from disk and cache without a JVM in the path. For Java application requests, the servlet container is not optional, and throughput is governed by the application code, JVM heap sizing, garbage collection behavior, and connection pool configuration — not by which server sits in front. The practical performance rule for a mixed workload is to keep static content off Tomcat and keep httpd out of the Java request path except as a thin proxy.

Operational differences

• Restart behavior. httpd supports graceful restarts that reload configuration without dropping in-flight requests. A Tomcat restart cycles the JVM — startup includes application initialization and can take from seconds to minutes depending on the application; rolling restarts behind a load balancer are the standard way to avoid downtime.
• Log locations. httpd writes access and error logs per virtual host, typically under /var/log/httpd or /var/log/apache2. Tomcat splits output across catalina.out, localhost logs, and per-application access logs in its logs directory, plus whatever framework logging the application configures.
• Upgrade cadence. httpd 2.4 has been the stable branch since 2012, with in-place point releases. Tomcat maintains several major branches in parallel, and moving between them can involve the Java EE to Jakarta EE namespace change (9.0.x to 10.1.x) — a code-level migration, not just a package upgrade.
• Tuning surface. httpd tuning centers on MPM worker/event settings and module selection. Tomcat tuning is largely JVM tuning: heap sizes, GC selection, and connector thread pools.

FAQ

Is Tomcat a web server or an application server?

Tomcat is a servlet container that includes an HTTP connector, so it functions as a web server for the Java applications it hosts. It implements a subset of Jakarta EE (Servlet, JSP, EL, WebSocket) rather than the full platform — full Jakarta EE application servers such as WildFly or Open Liberty add EJB, JMS, and the rest of the specification set.

Can Apache HTTP Server run Java applications?

No. httpd has no JVM and cannot execute servlets or WAR files. Java applications require a servlet container — Tomcat, Jetty, or a full application server — with httpd optionally in front as a reverse proxy.

Do I still need Apache if I use Spring Boot?

Not for running the application — Spring Boot's embedded Tomcat serves HTTP directly. A front-end proxy (httpd, nginx, or a cloud load balancer) is still common for TLS termination, static assets, and routing multiple applications behind one address, but it is an architectural choice rather than a requirement.