Apache Tomcat ist der meistgenutzte Java Servlet Container der Welt - und damit ein unverzichtbarer Bestandteil der Java-Web-Infrastruktur. Wenn du Java-Webanwendungen entwickelst, mit Spring Boot arbeitest oder Jakarta EE (ehemals Java EE) einsetzt, wirst du früher oder später mit Tomcat in Berührung kommen.

Wichtig zu verstehen: Tomcat ist kein klassischer Webserver wie Nginx oder Apache HTTP Server. Er ist ein Servlet Container - eine Laufzeitumgebung, die Java-Code ausführt und HTTP-Anfragen verarbeitet. Während Nginx statische Dateien ausliefert und als Reverse Proxy arbeitet, führt Tomcat deine Java-Anwendungen aus: Servlets, JSP-Seiten und moderne Spring Boot Anwendungen.

Die Geschichte von Tomcat reicht bis 1999 zurück, als Sun Microsystems den ursprünglichen Code an die Apache Software Foundation übergab. Seitdem hat sich Tomcat zum De-facto-Standard für Java-Web-Deployment entwickelt. Große Unternehmen wie LinkedIn, eBay und die Deutsche Bank setzen auf Tomcat. Und wenn du Spring Boot verwendest, nutzt du Tomcat bereits - der Servlet Container ist standardmäßig eingebettet.

In diesem Artikel erfährst du, wie Tomcat funktioniert, wie du ihn installierst und konfigurierst, und wann er die richtige Wahl für dein Projekt ist.

Technische Übersicht: Was macht Tomcat?

Um Tomcat zu verstehen, musst du zunächst die Grundkonzepte der Java-Web-Entwicklung kennen.

Servlets: Das Fundament

Ein Servlet ist eine Java-Klasse, die HTTP-Anfragen verarbeitet und HTTP-Antworten generiert. Statt wie bei PHP für jeden Request einen neuen Prozess zu starten, lädt Tomcat Servlets einmal in den Speicher und verarbeitet alle Anfragen mit demselben Objekt. Das ist deutlich effizienter.

@WebServlet("/hello")
public class HelloServlet extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest request,
                         HttpServletResponse response)
            throws ServletException, IOException {
        response.setContentType("text/html");
        response.getWriter().println("<h1>Hallo von Tomcat!</h1>");
    }
}

Tomcat implementiert die Jakarta Servlet API (früher Java Servlet API). Diese Spezifikation definiert, wie Servlets funktionieren, wie sie auf Requests reagieren und wie sie Sessions verwalten.

Jakarta EE: Der Standard

Mit Tomcat 10 erfolgte der Wechsel von Java EE zu Jakarta EE. Das bedeutet: Der Namespace änderte sich von javax.* zu jakarta.*. Wenn du ältere Anwendungen migrierst, musst du alle Imports anpassen - oder Tomcat 9.x verwenden, das noch den alten Namespace unterstützt.

Tomcat implementiert folgende Jakarta EE Spezifikationen:

Servlet 6.0 (Tomcat 10.1.x)
JSP 3.1 (JavaServer Pages)
EL 5.0 (Expression Language)
WebSocket 2.1

Connectors: Die Schnittstelle zur Außenwelt

Tomcat verwendet Connectors, um HTTP-Anfragen zu empfangen:

Coyote HTTP/1.1: Der Standard-Connector für direkten HTTP-Zugriff
Coyote HTTP/2: Für HTTP/2-Unterstützung
AJP (Apache JServ Protocol): Für die Kommunikation mit vorgeschalteten Webservern wie Apache HTTP Server

In den meisten modernen Setups verwendest du den HTTP-Connector direkt oder stellst Nginx als Reverse Proxy vor Tomcat.

Embedded vs. Standalone

Es gibt zwei Wege, Tomcat zu nutzen:

Embedded Tomcat: Spring Boot bettet Tomcat direkt in deine Anwendung ein. Du packst alles in eine einzige JAR-Datei, die du mit java -jar app.jar startest. Kein separater Tomcat-Server nötig.

Standalone Tomcat: Du installierst Tomcat als eigenständigen Server und deployst deine Anwendungen als WAR-Dateien. Das ist der klassische Enterprise-Ansatz, bei dem mehrere Anwendungen auf einem Server laufen.

Tomcat vs. andere Java-Server

Die Java-Welt bietet mehrere Alternativen zu Tomcat. Hier ein Überblick über die wichtigsten Unterschiede.

Tomcat vs. Jetty

Jetty ist der Hauptkonkurrent von Tomcat. Entwickelt von der Eclipse Foundation, ist Jetty besonders bei Entwicklern beliebt, die einen leichtgewichtigen Server bevorzugen.

Jetty startet schneller als Tomcat und hat einen kleineren Memory-Footprint. Dafür ist die Community kleiner, und die Dokumentation ist weniger umfangreich. Jetty wird oft für Microservices und eingebettete Szenarien bevorzugt.

Tomcat vs. WildFly

WildFly (früher JBoss) ist ein vollständiger Jakarta EE Application Server. Während Tomcat nur Servlets und JSP unterstützt, bietet WildFly zusätzlich:

EJB (Enterprise JavaBeans)
JPA (Java Persistence API)
JMS (Java Message Service)
CDI (Contexts and Dependency Injection)

Wenn du diese Enterprise-Features brauchst, ist WildFly die richtige Wahl. Für Spring Boot Anwendungen ist WildFly jedoch Overkill - hier reicht Tomcat völlig aus.

Tomcat vs. Undertow

Undertow ist Red Hats moderner, nicht-blockierender Webserver. Er ist der Standard-Server in WildFly und kann auch standalone oder eingebettet genutzt werden. Spring Boot unterstützt Undertow als Alternative zu Tomcat.

Undertow ist performanter als Tomcat bei sehr hoher Concurrency, aber komplexer zu konfigurieren und weniger dokumentiert.

Vergleichstabelle

Feature	Tomcat	Jetty	WildFly	Undertow
Typ	Servlet Container	Servlet Container	Full EE Server	Webserver
Jakarta EE	Servlet, JSP	Servlet, JSP	Komplett	Servlet
Memory	~50-100 MB	~30-70 MB	~200-400 MB	~20-50 MB
Startzeit	2-5 Sek.	1-3 Sek.	5-15 Sek.	1-2 Sek.
Spring Boot Default	Ja	Optional	Nein	Optional
Community	Sehr groß	Mittel	Groß	Klein

Installation & Konfiguration

Tomcat lässt sich auf verschiedene Weisen installieren. Hier zeige ich dir die wichtigsten Methoden.

Standalone Installation

Die manuelle Installation gibt dir volle Kontrolle. Lade zunächst Tomcat von der offiziellen Seite herunter:

# Tomcat 10.1.x herunterladen (Version anpassen)
wget https://dlcdn.apache.org/tomcat/tomcat-10/v10.1.19/bin/apache-tomcat-10.1.19.tar.gz

# Entpacken
tar xzf apache-tomcat-10.1.19.tar.gz

# In Verzeichnis wechseln
cd apache-tomcat-10.1.19

# Ausführungsrechte setzen
chmod +x bin/*.sh

# Tomcat starten
./bin/startup.sh

Nach dem Start erreichst du Tomcat unter http://localhost:8080. Du siehst die Standard-Willkommensseite.

Verzeichnisstruktur

Die Tomcat-Installation hat eine klare Struktur:

Verzeichnis	Beschreibung
`bin/`	Startup- und Shutdown-Skripte
`conf/`	Konfigurationsdateien (server.xml, web.xml)
`lib/`	Tomcat-Bibliotheken und Servlet API
`logs/`	Log-Dateien (catalina.out, access_log)
`webapps/`	Hier deployst du deine Anwendungen
`work/`	Kompilierte JSPs und temporäre Dateien
`temp/`	Temporäre Dateien der JVM

server.xml: Die Hauptkonfiguration

Die wichtigste Konfigurationsdatei ist conf/server.xml. Hier definierst du Connectors, Hosts und andere Server-Einstellungen:

<Server port="8005" shutdown="SHUTDOWN">
  <Service name="Catalina">

    <!-- HTTP Connector -->
    <Connector port="8080"
               protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443"
               maxThreads="200"
               minSpareThreads="10" />

    <!-- HTTPS Connector (optional) -->
    <Connector port="8443"
               protocol="org.apache.coyote.http11.Http11NioProtocol"
               maxThreads="150"
               SSLEnabled="true">
      <SSLHostConfig>
        <Certificate certificateKeystoreFile="conf/keystore.jks"
                     certificateKeystorePassword="changeit"
                     type="RSA" />
      </SSLHostConfig>
    </Connector>

    <Engine name="Catalina" defaultHost="localhost">
      <Host name="localhost" appBase="webapps"
            unpackWARs="true" autoDeploy="true">
      </Host>
    </Engine>

  </Service>
</Server>

context.xml: Anwendungskonfiguration

In conf/context.xml konfigurierst du globale Ressourcen wie Datenbankverbindungen:

<Context>
  <!-- Datenbankverbindung als JNDI Resource -->
  <Resource name="jdbc/MyDB"
            auth="Container"
            type="javax.sql.DataSource"
            maxTotal="100"
            maxIdle="30"
            maxWaitMillis="10000"
            username="dbuser"
            password="dbpassword"
            driverClassName="com.mysql.cj.jdbc.Driver"
            url="jdbc:mysql://localhost:3306/mydb"/>
</Context>

WAR Deployment

Um eine Anwendung zu deployen, kopiere die WAR-Datei einfach in das webapps/-Verzeichnis:

cp myapp.war $CATALINA_HOME/webapps/

Tomcat entpackt die WAR automatisch und startet die Anwendung. Du erreichst sie unter http://localhost:8080/myapp.

Spring Boot Integration

Die meisten modernen Java-Webanwendungen werden mit Spring Boot entwickelt - und Spring Boot nutzt Tomcat standardmäßig als eingebetteten Server.

Embedded Tomcat: Der Standard

Wenn du ein Spring Boot Projekt erstellst, ist Tomcat bereits dabei. Die Abhängigkeit spring-boot-starter-web bringt den eingebetteten Tomcat mit:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

Du brauchst keinen separaten Server zu installieren. Ein mvn package erstellt eine ausführbare JAR:

mvn package
java -jar target/myapp-1.0.0.jar

Die Anwendung startet mit eingebettetem Tomcat auf Port 8080.

Konfiguration über application.properties

Spring Boot konfiguriert Tomcat über die application.properties oder application.yml:

# Server-Port
server.port=8080

# Tomcat-spezifische Einstellungen
server.tomcat.max-threads=200
server.tomcat.min-spare-threads=10
server.tomcat.accept-count=100
server.tomcat.max-connections=10000

# Connection Timeout
server.tomcat.connection-timeout=20000

# Compression aktivieren
server.compression.enabled=true
server.compression.mime-types=text/html,text/xml,text/plain,application/json

# Access Log aktivieren
server.tomcat.accesslog.enabled=true
server.tomcat.accesslog.pattern=%h %l %u %t "%r" %s %b %D

JAR vs. WAR: Wann was?

JAR-Deployment (Standard):

Eine Datei enthält alles
Einfach zu deployen und zu starten
Ideal für Microservices und Container (Docker, Kubernetes)
Empfohlen für neue Projekte

WAR-Deployment (klassisch):

Anwendung wird auf existierendem Tomcat deployt
Mehrere Anwendungen auf einem Server möglich
Erforderlich bei manchen Enterprise-Umgebungen
Nötig für Legacy-Integrationen

Für WAR-Deployment musst du die pom.xml anpassen:

<packaging>war</packaging>

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-tomcat</artifactId>
        <scope>provided</scope>
    </dependency>
</dependencies>

Und eine SpringBootServletInitializer-Klasse erstellen:

@SpringBootApplication
public class MyApplication extends SpringBootServletInitializer {

    @Override
    protected SpringApplicationBuilder configure(
            SpringApplicationBuilder application) {
        return application.sources(MyApplication.class);
    }

    public static void main(String[] args) {
        SpringApplication.run(MyApplication.class, args);
    }
}

Wann Standalone Tomcat?

Es gibt Szenarien, in denen ein dedizierter Tomcat-Server sinnvoll ist:

Multi-App-Deployment: Mehrere Anwendungen sollen auf einem Server laufen
Legacy-Systeme: Integration mit bestehender Tomcat-Infrastruktur
Enterprise-Anforderungen: Zentrale Verwaltung durch Operations-Team
Shared Hosting: Wenn du keinen Root-Zugriff hast

Für Microservices und Container-Deployments ist Embedded Tomcat die bessere Wahl.

Performance & Tuning

Tomcat kann bei richtiger Konfiguration enorme Lasten verarbeiten. Hier die wichtigsten Tuning-Maßnahmen.

JVM-Tuning

Die JVM-Einstellungen haben den größten Einfluss auf die Performance. Setze sie in bin/setenv.sh:

#!/bin/bash
export CATALINA_OPTS="$CATALINA_OPTS -Xms512m -Xmx2048m"
export CATALINA_OPTS="$CATALINA_OPTS -XX:+UseG1GC"
export CATALINA_OPTS="$CATALINA_OPTS -XX:MaxGCPauseMillis=200"
export CATALINA_OPTS="$CATALINA_OPTS -XX:+HeapDumpOnOutOfMemoryError"
export CATALINA_OPTS="$CATALINA_OPTS -XX:HeapDumpPath=/var/log/tomcat/"

Wichtige Einstellungen:

-Xms/-Xmx: Minimaler und maximaler Heap. Setze beide gleich, um dynamische Größenänderungen zu vermeiden
-XX:+UseG1GC: Der G1 Garbage Collector ist für Server-Workloads optimiert
-XX:MaxGCPauseMillis: Ziel-Pausenzeit für GC (in Millisekunden)

Connector-Tuning

Die Connector-Einstellungen in server.xml bestimmen, wie viele Anfragen Tomcat gleichzeitig verarbeiten kann:

<Connector port="8080"
           protocol="org.apache.coyote.http11.Http11NioProtocol"
           maxThreads="200"
           minSpareThreads="25"
           acceptCount="100"
           maxConnections="10000"
           connectionTimeout="20000"
           enableLookups="false"
           compression="on"
           compressionMinSize="2048"
           compressibleMimeType="text/html,text/xml,text/plain,application/json"/>

maxThreads: Maximale Anzahl gleichzeitiger Request-Threads
acceptCount: Queue-Größe für wartende Verbindungen
maxConnections: Maximale Anzahl offener Verbindungen
enableLookups="false": DNS-Lookups deaktivieren (Performance!)

Connection Pool

Für Datenbankverbindungen ist ein Connection Pool essentiell. HikariCP ist der schnellste Pool und Spring Boot Standard:

# application.properties
spring.datasource.hikari.maximum-pool-size=20
spring.datasource.hikari.minimum-idle=5
spring.datasource.hikari.idle-timeout=300000
spring.datasource.hikari.connection-timeout=20000

Caching vor Tomcat

Tomcat ist nicht für statische Inhalte optimiert. Stelle Nginx oder Varnish davor:

upstream tomcat {
    server 127.0.0.1:8080;
    keepalive 32;
}

server {
    listen 80;
    server_name example.com;

    # Statische Dateien direkt ausliefern
    location /static/ {
        alias /var/www/static/;
        expires 30d;
    }

    # Dynamische Anfragen an Tomcat
    location / {
        proxy_pass http://tomcat;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Sicherheit

Ein produktiver Tomcat-Server muss abgesichert werden. Hier die wichtigsten Maßnahmen.

Manager App absichern

Die Tomcat Manager App (/manager/html) ermöglicht das Deployment von Anwendungen über den Browser. In Produktion solltest du sie entweder deaktivieren oder stark absichern:

<!-- conf/tomcat-users.xml -->
<tomcat-users>
  <role rolename="manager-gui"/>
  <role rolename="manager-script"/>
  <user username="admin"
        password="SEHR_LANGES_SICHERES_PASSWORT"
        roles="manager-gui,manager-script"/>
</tomcat-users>

Zusätzlich den Zugriff auf bestimmte IPs beschränken (webapps/manager/META-INF/context.xml):

<Context antiResourceLocking="false" privileged="true">
  <Valve className="org.apache.catalina.valves.RemoteAddrValve"
         allow="127\.0\.0\.1|192\.168\.1\.\d+"/>
</Context>

SSL/TLS konfigurieren

Für HTTPS benötigst du ein Zertifikat. Mit Let's Encrypt und einem Keystore:

# Keystore erstellen
keytool -genkey -alias tomcat -keyalg RSA -keystore keystore.jks -keysize 2048

# Let's Encrypt Zertifikat importieren
keytool -import -alias tomcat -file fullchain.pem -keystore keystore.jks

Konfiguration in server.xml:

<Connector port="8443"
           protocol="org.apache.coyote.http11.Http11NioProtocol"
           maxThreads="150"
           SSLEnabled="true">
  <SSLHostConfig protocols="TLSv1.2,TLSv1.3">
    <Certificate certificateKeystoreFile="conf/keystore.jks"
                 certificateKeystorePassword="changeit"
                 type="RSA" />
  </SSLHostConfig>
</Connector>

Tomcat hinter Reverse Proxy

Die beste Sicherheitspraxis: Stelle Nginx vor Tomcat. Nginx übernimmt SSL-Termination und ist als Internet-facing Server besser gehärtet.

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Host $host;
    }
}

Tomcat muss dann die Proxy-Header verarbeiten (server.xml):

<Valve className="org.apache.catalina.valves.RemoteIpValve"
       remoteIpHeader="X-Forwarded-For"
       protocolHeader="X-Forwarded-Proto"/>

Vor- und Nachteile

Vorteile

De-facto Standard für Java-Web Tomcat ist der mit Abstand populärste Java Servlet Container. Die meisten Java-Entwickler kennen ihn, und die meisten Java-Web-Frameworks sind dafür optimiert.

Exzellente Spring Boot Integration Spring Boot nutzt Tomcat als Standard-Server. Die Integration ist nahtlos, die Konfiguration einfach. Du kannst sofort loslegen ohne zusätzliche Setup-Schritte.

Leichtgewichtig im Vergleich zu Application Servern Im Vergleich zu WildFly oder WebSphere ist Tomcat schlank. Er startet schneller, verbraucht weniger Speicher und ist einfacher zu administrieren.

Große Community und Dokumentation Die Tomcat-Community ist riesig. Für jedes Problem findest du Stack Overflow Antworten, Tutorials und Beispiele. Die offizielle Dokumentation ist umfangreich und gut gepflegt.

Kostenlos und Open Source Tomcat ist Apache-lizenziert. Du kannst ihn kostenlos für kommerzielle Projekte nutzen, modifizieren und verteilen.

Bewährt und stabil Mit über 25 Jahren Geschichte ist Tomcat extrem ausgereift. Kritische Bugs sind selten, Sicherheitsupdates erscheinen zeitnah.

Nachteile

Nur für Java Tomcat führt ausschließlich Java-Code aus. Für PHP, Python oder Node.js brauchst du andere Server.

Braucht JVM (Overhead) Tomcat läuft auf der Java Virtual Machine. Das bedeutet: Mindestens 256 MB RAM für den Start, typischerweise 512 MB bis mehrere GB für produktive Anwendungen. Für kleine VPS kann das zu viel sein.

Nicht für statische Inhalte optimiert Tomcat kann statische Dateien ausliefern, ist aber langsamer als Nginx. Für optimale Performance solltest du Nginx vorschalten.

Kein HTTP/3 Stand 2026 unterstützt Tomcat noch kein HTTP/3 nativ. Wenn du HTTP/3 brauchst, musst du Nginx oder Caddy als Reverse Proxy einsetzen.

Konfiguration komplex Die XML-basierte Konfiguration in server.xml ist mächtig, aber auch komplex. Die Lernkurve für fortgeschrittene Konfigurationen ist steil.

Fazit: Wann ist Tomcat die richtige Wahl?

Apache Tomcat ist der bewährte Standard für Java-Webanwendungen. Nach über 25 Jahren aktiver Entwicklung ist er ausgereift, stabil und hervorragend dokumentiert.

Tomcat ist ideal für dich, wenn:

Du Java-Webanwendungen mit Spring Boot entwickelst
Du Jakarta EE Servlets und JSPs nutzt
Du eine große Community und gute Dokumentation schätzt
Du einen leichtgewichtigen Server ohne Full-EE-Overhead brauchst
Dein Team bereits Java-Erfahrung hat

Tomcat ist weniger geeignet, wenn:

Du kein Java verwendest
Du minimalen Speicherverbrauch brauchst (< 256 MB)
Du HTTP/3 nativ benötigst
Du nur statische Dateien ausliefern willst

Für Spring Boot Projekte ist Tomcat die natürliche Wahl - er ist bereits eingebettet und funktioniert out-of-the-box. Für Microservices und Container-Deployments nutzt du den eingebetteten Tomcat. Für Enterprise-Umgebungen mit mehreren Anwendungen kann ein dedizierter Tomcat-Server sinnvoll sein.

Zurück zum Webserver-Vergleich 2026

Weiterführende Ressourcen

Hier findest du weitere Informationen zu Tomcat und verwandten Themen:

Apache Tomcat Dokumentation - Die offizielle Referenz
Spring Boot lernen - Teil 1 - Erste Schritte mit Spring Boot und eingebettetem Tomcat
Nginx Webserver 2026 - Nginx als Reverse Proxy vor Tomcat

Letzte Aktualisierung: März 2026

Ähnliche Artikel

Java Spring Boot lernen: Grundlagen anhand eines echten Open-Source-Projekts

Apache HTTP Server 2026: Der Klassiker im modernen Einsatz

Caddy Webserver 2026: Automatisches HTTPS & Zero-Config

Möchtest du auch so einen Blog?