When preparing a deployable Tomcat build for a UK hosting environment, the goal is to upload only what the application needs to run cleanly inside the container. A good build should include your application code, web resources, configuration files required at runtime, and any custom libraries that are not already provided by the hosting platform or Tomcat installation. It should not include development files, source-only dependencies, or a full application server distribution.
For a managed Java hosting setup such as My App Server in Plesk, this approach keeps deployments predictable and makes it easier to install, restart, and troubleshoot your own Apache Tomcat instance or private JVM. If you are deploying a WAR file, the same principles apply: package the app in a way that Tomcat can unpack and run without manual cleanup after each upload.
What a deployable Tomcat build should contain
A deployable Tomcat build should be ready for execution in the webapps directory or uploaded as a WAR archive, depending on how your hosting service is configured. At minimum, it should contain:
- Compiled application classes
- Web content such as JSP, HTML, CSS, JavaScript, and images
- Application-specific configuration files
- Required third-party JARs that are not supplied by the runtime
- Deployment descriptors such as
web.xmlwhen your app uses them - Any custom resources needed at startup, for example properties files or templates
If you are using a My App Server setup, remember that Tomcat runs as a service controlled from the hosting panel. This means your deployment package should be complete enough for Tomcat to start the application after upload, without requiring manual changes on the server each time.
Files and folders that usually belong in a deployable build
Compiled Java classes
Your compiled classes should be included under WEB-INF/classes if you are building a traditional web application. These are the files Tomcat loads at runtime. Do not upload source .java files unless your build process specifically depends on them being present, which is uncommon in standard deployment.
Example structure:
WEB-INF/classes/com/example/app/Controller.classWEB-INF/classes/com/example/app/Service.class
Application libraries
Any JAR files your application needs should normally go into WEB-INF/lib. This includes frameworks, database drivers, utility libraries, and other dependencies that are not already available in the Tomcat installation or provided by the hosting environment.
Keep the dependency set minimal and intentional. If a library is available both in the application package and on the server, version conflicts can occur. In a hosting platform where you manage your own Tomcat or JVM through Plesk, it is still better to package only what your application specifically requires.
Web resources
All files served directly to the browser should be included in the web root of your application package. This usually means:
- JSP files
- HTML pages
- CSS stylesheets
- JavaScript files
- Images and icons
- Fonts and static assets
These resources should be placed in the correct structure so Tomcat can serve them without extra configuration.
Deployment descriptors and runtime config
Depending on how your application is written, you may need:
WEB-INF/web.xml- Spring or framework-specific config files
- Logging configuration files
- Environment-specific properties
- Context configuration if the app needs one
Only include configuration files that are meant to travel with the build. Sensitive secrets, such as production passwords, should be handled carefully and stored according to your hosting and deployment policy.
What should not be included in the build
One of the most common deployment mistakes is packaging too much. A clean Tomcat build should avoid the following:
- Source code repositories such as
.gitfolders - IDE files from Eclipse, IntelliJ IDEA, NetBeans, or VS Code
- Build tool caches and temporary files
- Compiled artifacts from multiple environments unless they are needed
- Duplicate copies of the same library
- Full Tomcat binaries or server installation files
- Local test data, logs, and debug dumps
Including these files increases deployment size and can create confusing behaviour on a hosted Tomcat service. For example, stale classes or duplicate JARs may cause one version of a class to be loaded during development and another after upload.
WAR file vs exploded directory deployment
WAR file deployment
A WAR file is the most common deployable format for Tomcat. It packages your application into a single archive that Tomcat can deploy automatically. This is often the simplest option for hosted Java applications because it makes upload and rollback easier.
Use a WAR file when:
- You want a single deployable artifact
- Your hosting panel supports direct upload
- You need consistent deployments
- You want to replace old versions cleanly
Exploded deployment
An exploded deployment is a directory structure rather than a zipped archive. This can be useful during testing or when you need to inspect files directly on the server. Some managed hosting setups allow this through file upload or file manager access.
Use an exploded build when:
- You need easier inspection of deployed files
- You are working with frequent content updates
- Your deployment process expects a directory tree
For most production-style uploads in a shared hosting or Plesk-managed Java hosting account, a WAR file is usually the more practical choice.
Recommended Tomcat build structure
A typical deployable web application structure looks like this:
myapp.warWEB-INF/WEB-INF/classes/WEB-INF/lib/WEB-INF/web.xml- public static resources in the web root
If you are building manually, verify that the package contents match the structure expected by Tomcat. If you are using Maven, Gradle, or another build tool, review the generated archive before upload and remove any unnecessary items.
How to prepare a clean deployable build
1. Separate development files from runtime files
Keep your source code, test classes, and project configuration separate from the runtime package. The deployment artifact should be the output of your build process, not the full project workspace.
2. Include only required dependencies
Review your dependency tree and confirm which JARs your application really needs at runtime. Remove duplicates and unused libraries. This is especially important in a Tomcat hosting environment where the application should remain self-contained and stable.
3. Verify Java version compatibility
Make sure your compiled bytecode matches the Java version available in your hosting environment. If your Tomcat installation uses a specific JVM version in My App Server, compile your application for that version. A build compiled for a newer Java release will not start correctly on an older runtime.
4. Test the package before upload
Run the packaged application locally or in a staging environment first. Check that the application starts, pages load, and resources resolve correctly. If your app uses external services such as a database, make sure the configuration values are ready for the hosted environment.
5. Remove stale output
Clean your build directory before generating the final package. Old class files or outdated libraries can survive across builds and create hard-to-diagnose issues after deployment.
Tomcat-specific files that may be needed
Depending on the application, your build may need some Tomcat-specific or servlet-specific configuration. Common examples include:
web.xmlfor servlet mappings and startup configuration- Session configuration if your app depends on specific timeout behaviour
- Error pages defined for custom error handling
- Filter and listener definitions
- Character encoding rules for request and response handling
If your hosting platform provides a private Tomcat instance or service control through Plesk, these settings are usually managed at the application level rather than by editing the global server installation. That keeps one application from affecting another.
Common build mistakes and how to avoid them
Packaging the whole project instead of the deployable output
Many developers upload the full project folder by mistake. This often includes source files, test directories, documentation, and IDE metadata. Always deploy the final output only.
Duplicating libraries
If the same library is placed in more than one location, Tomcat may load an unexpected version. Check both the application archive and any shared library locations in your hosting setup.
Missing runtime dependencies
If the application works locally but fails after upload, a missing JAR is often the reason. Review startup errors and confirm that every required dependency is included in WEB-INF/lib or otherwise available in the environment.
Incorrect folder layout
Tomcat is strict about web application structure. A misplaced web.xml file or library folder can prevent the application from starting. Validate the package layout before deployment.
Using server-side files that belong outside the app
Do not bundle global server settings, Tomcat installation files, or host-level service files into the application package. In managed hosting, those are handled separately by the platform and service controls.
How this fits a managed Tomcat hosting setup
With a managed hosting platform such as My App Server, you may have the option to install a ready-made Tomcat version or configure a custom Java/Tomcat stack. In both cases, the application build should be designed for portability. That means it should rely on the selected Java runtime and the Tomcat container, but not on manual changes to the server installation after every deployment.
This model is practical for Java hosting, JSP hosting, servlet hosting, and small to medium applications that need a private JVM with controlled service management. You can upload a WAR, restart the Tomcat service from the control panel, and keep the deployment process straightforward.
Practical checklist before deploying
- Confirm the target Java version
- Build a clean WAR or exploded package
- Include
WEB-INF/classesandWEB-INF/lib - Verify all JSP, HTML, CSS, JS, and image files are present
- Check
web.xmland any framework config files - Remove IDE files, source control folders, and logs
- Test the archive locally if possible
- Upload only the final deployable output
Example of a clean deployable Tomcat package
A simple web application package might contain:
index.jsplogin.jspassets/css/site.cssassets/js/app.jsWEB-INF/web.xmlWEB-INF/classes/com/example/MainServlet.classWEB-INF/lib/mysql-connector-j.jar
This is usually enough for a standard deployment on a hosted Tomcat service, assuming the Java version and library versions are compatible.
FAQ
Should I include the Tomcat installation in my build?
No. The build should contain your application only. The Tomcat runtime is provided separately by the hosting platform or your own managed service instance.
Do I need source files in a deployable WAR?
Usually no. Tomcat runs compiled classes and web resources. Source files should stay in your development project, not in the deployment artifact.
Where should third-party JAR files go?
Place application-specific libraries in WEB-INF/lib unless your hosting architecture explicitly requires a shared library location.
Can I deploy a project folder instead of a WAR?
Yes, if your hosting setup supports an exploded deployment. However, a WAR is often simpler and safer for regular uploads.
What happens if I use the wrong Java version?
The application may fail to start, throw class version errors, or behave unexpectedly. Always match your build target to the runtime Java version used by your Tomcat service.
Should logs be part of the package?
No. Logs are runtime output and should not be included in the deployable build.
Can I include configuration files with passwords?
Only if your deployment process is designed for it and you understand the security implications. In many hosting setups, secrets are better stored outside the package or injected through environment-specific configuration.
Conclusion
A deployable Tomcat build should be complete, clean, and focused on runtime needs only. Include compiled classes, required libraries, web resources, and the configuration files the application needs to start. Exclude development clutter, server binaries, logs, and unnecessary dependencies. In a managed Java hosting environment with Plesk and My App Server, this approach helps you deploy faster, reduce version conflicts, and keep your Tomcat application easier to maintain.
If you are preparing a build for upload, the safest rule is simple: package what Tomcat needs to run the application, and nothing more.