How to Deploy Tomcat in Production: Directory Separation, Soft Links & Scripts

Introduction

Many online articles only cover basic Tomcat configuration and startup, but real‑world production deployment differs significantly. This article shares practical steps for deploying Tomcat in production, focusing on aspects rarely covered in tutorials.

Tomcat Components

Tomcat consists of several core components: Connector (receives external requests), Engine (processes requests), Host (maps domain names), and Context (maps paths to web applications). The Host and Context are the two key components for distinguishing projects.

1. Connector receives requests on a configured port. 2. Connector forwards the request to the Engine. 3. Engine selects the appropriate Host based on the domain. 4. Host assigns the request to a Context based on the path.

Deployment Directory

The standard approach is to drop a WAR file into webapps. However, when multiple applications (e.g., Web‑A and Web‑B) need different runtime parameters or independent lifecycle management, a more flexible layout is required.

Directory Planning

Place the Tomcat installation under /usr/local. To simplify version upgrades, create a symbolic link (e.g., /usr/local/tomcat) pointing to the actual version directory. When upgrading from Tomcat 8.5 to 9.x, only the link needs to be updated.

Directory Separation

Separate Tomcat binaries from web applications using CATALINA_HOME (Tomcat installation) and CATALINA_BASE (individual web‑app environment). Create a /usr/local/web‑apps directory to hold all web applications, then create subdirectories web‑a and web‑b for each project. Copy the conf directory into each subdirectory so each app has its own configuration files, and create webapps and logs directories inside them.

Startup Script

A custom tomcat.sh script sets CATALINA_BASE="`pwd`" to make the current directory the web‑app base, then launches Tomcat with the appropriate configuration. After granting execution permission ( chmod +x tomcat.sh), modify conf/server.xml so appBase and docBase are relative to CATALINA_BASE. Running the script starts the isolated instance, and accessing http://192.168.31.150:8080/ returns the index.html of the selected web app.

Note: Some organizations prefer configuring hosts and contexts via files under conf/Catalina rather than editing server.xml . This approach is less relevant once applications are fully separated.

Conclusion

The article highlights essential production‑grade Tomcat deployment techniques, including directory separation, symbolic links for version management, and custom startup scripts. For automated deployment of WAR/JAR packages, tools like Jenkins can be integrated.