Install Tomcat 10.1 on Ubuntu 24.04 LTS with APT

Using distribution packages for Tomcat 10.1 on Ubuntu 24.04 LTS keeps service, account and update management together. This guide targets a new, separate host. Do not attempt an in-place conversion of a manual /opt/tomcat installation by simply installing the package; prepare migration and rollback first.

Tomcat 10.1 requires Java 11 or later. Here we use Ubuntu's OpenJDK 21 runtime. Confirm application compatibility with that Java version and the Jakarta Servlet API before deployment; an older Java EE WAR is not automatically compatible. See Apache's installation requirements and the Ubuntu OpenJDK package.

Restrict access before installing

Connect with a sudo-capable account. Package installation may start the service automatically, so first verify that your cloud security group or existing firewall prevents public access to port 8080. Preserve SSH access. Nothing here requires disabling the firewall or resetting existing rules.

cat /etc/os-release
sudo ss -ltnp
sudo apt update
apt-cache policy tomcat10 openjdk-21-jre-headless

Confirm Ubuntu 24.04 and an available package candidate. tomcat10 is in Universe. If no candidate appears, inspect official repository components and update sources instead of adding a random PPA. A version listed in the base-release repository is not proof of the newest security fix. Review the Ubuntu package record, your candidate and its security-maintenance coverage together.

Install the runtime and service

sudo apt install openjdk-21-jre-headless tomcat10 curl
java -version
dpkg-query -W tomcat10 libtomcat10-java openjdk-21-jre-headless
sudo systemctl stop tomcat10
sudo systemctl cat tomcat10

Read the proposed package changes before accepting them. Confirm that the selected Tomcat branch is 10.1. Do not create a second tomcat.service or an additional service account alongside the packaged service. The shell's Java version alone does not establish the service runtime; inspect its unit, startup scripts and startup logs as well.

Bind HTTP to loopback

Inspect the packaged configuration layout:

sudo ls -l /etc/tomcat10/server.xml
dpkg -L tomcat10
sudo cp -a /etc/tomcat10/server.xml /etc/tomcat10/server.xml.before-loopback
sudoedit /etc/tomcat10/server.xml

If the backup name exists, choose another unused name. If the configuration file is absent, stop and inspect the installed layout. Add address="127.0.0.1" to the existing HTTP Connector in server.xml. Do not create a duplicate port-8080 connector or discard other settings blindly. A simplified example of that element is:

<Connector address="127.0.0.1"
           port="8080"
           protocol="HTTP/1.1"
           connectionTimeout="20000" />

The address setting in the HTTP Connector reference controls its listening interface. Loopback suits a reverse proxy on the same host; a separate proxy host cannot reach it. That design needs a private-network address and appropriately restricted access instead.

Check service state, listener and HTTP separately

sudo systemctl enable --now tomcat10
sudo systemctl status tomcat10 --no-pager
sudo journalctl -u tomcat10 -n 100 --no-pager
sudo ss -ltnp 'sport = :8080'
curl --connect-timeout 3 --max-time 10 -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/

Expect the 8080 listener on 127.0.0.1. If it appears on 0.0.0.0 or [::], correct the binding before exposing the host. A 404 can demonstrate that an HTTP server answered, not that a root application is installed. Connection refusal calls for checking the service, port and address. Redact sensitive data before sharing logs.

Inspect remotely without opening port 8080

From your workstation, create an SSH tunnel:

ssh -N -L 18080:127.0.0.1:8080 user@server

Replace the example username and server. While the tunnel is open, visit http://127.0.0.1:18080/ locally; close it with Ctrl+C when finished. This is not a public application deployment.

Before production, deploy a compatible application in staging and test authentication, database access and restart behavior. Configure HTTPS reverse proxying, trusted proxy headers and application redirects separately. Do not install Manager/Host Manager components unless needed, and never use shared or example administrator passwords. Review the Apache security guide.

Maintain the packaged installation through apt and repeat service/application checks after updates. If migrating from the CentOS 7 installation or the older manual Ubuntu setup, transfer application and configuration differences deliberately rather than copying the entire old tree into package-managed directories.