When a Tomcat application works on your local machine but fails after upload, the most common cause is not the Tomcat code itself. In most cases, the application was built or packaged in a way that depends on the local environment, while the hosting platform uses a different Java runtime, a different Tomcat version, or a stricter deployment layout.
This is especially important on shared Java hosting where Tomcat is managed through a control panel such as Plesk. In that setup, the application usually runs inside a dedicated service with its own JVM, configured version, and deployment rules. A project that starts correctly in an IDE or local Tomcat installation may still fail after upload if the WAR file, libraries, context settings, or Java compatibility are incomplete.
Why the application works locally but not on the hosting platform
Local development often hides deployment problems. On your own computer, the app may run because your IDE adds libraries automatically, uses a newer JDK, loads files from the project directory, or reads environment variables that are not available after upload.
On a hosting platform, Tomcat typically runs in a cleaner and more controlled environment. That means:
- Only the files packaged into the WAR are available.
- The Java version may differ from your local JDK.
- The Tomcat version may differ from your local installation.
- File paths are often case-sensitive on Linux-based systems.
- External libraries must be included correctly inside the build output.
- Server-side permissions and startup settings are more restrictive.
If your app uses a private JVM or a managed Tomcat service, the hosting panel may give you control over Java version and service state, but it still expects the application to be packaged correctly before deployment.
Most common build and packaging problems
Missing JAR files in the WAR
One of the most frequent reasons for failure after upload is missing dependencies. Your application may compile in Eclipse, IntelliJ IDEA, or NetBeans because the IDE can see libraries from the project setup. However, if those JARs are not bundled into the WAR, Tomcat on the hosting platform cannot load them.
Typical signs include:
ClassNotFoundExceptionNoClassDefFoundErrorUnable to initialize main class- Application deploys, but specific pages fail at runtime
Check whether the required libraries are included in:
WEB-INF/libinside the WAR- Your build tool output, such as Maven or Gradle packaging
Wrong build output structure
A valid web application for Tomcat must have the expected structure. If the archive is uploaded with the wrong folder layout, Tomcat may not recognize it correctly.
A standard WAR should usually contain:
WEB-INF/WEB-INF/web.xmlif your app uses deployment descriptorsWEB-INF/classes/for compiled classesWEB-INF/lib/for dependency JARs
If your upload contains an extra top-level folder, such as myapp/myapp/WEB-INF instead of myapp/WEB-INF, deployment may fail or the app may appear under an unexpected path.
Using classes from the IDE output folder instead of packaging them
Some local setups run directly from the project build output directory. This works on your workstation but does not translate to hosting. After upload, Tomcat only reads the deployed application archive or exploded application directory.
If your code compiles locally but fails after deployment, verify that your build process creates a proper WAR file and that the classes end up in the archive, not only in your local target, build, or IDE output folder.
Including libraries with the wrong scope
Build tools allow dependency scopes such as compile, provided, runtime, and test. A common mistake is marking a dependency as provided when Tomcat on the hosting account does not supply that library.
Use provided only for APIs that are truly available in the runtime environment. If the application needs the library during execution and the server does not offer it, the dependency must be bundled into the WAR.
Java version mismatch after upload
Another common cause is Java compatibility. Your local machine may use a newer JDK, while the hosting account uses a different Java runtime selected through the control panel or service settings.
Symptoms of Java version mismatch may include:
- Application fails during startup
UnsupportedClassVersionError- Code using newer language features does not run
- Framework or library version is not compatible with the selected JVM
Before uploading, confirm:
- Which Java version your app was compiled against
- Which Java version the hosting service is using
- Whether the app depends on modules or APIs removed in newer releases
In a managed Tomcat environment, changing the Java version may be possible through the hosting panel or My App Server settings. If your app requires a specific version, make sure the compiled bytecode matches the runtime version configured for the service.
Tomcat version differences that affect deployment
A project that works locally on one Tomcat version may fail on another. The reason is often the use of APIs, configuration syntax, or servlet features that behave differently across Tomcat releases.
Examples include:
- Servlet API version differences
- Changes in JSP handling
- Security restrictions
- Context configuration differences
- Deprecated or removed configuration elements
If you are using a Tomcat hosting service with selectable versions, make sure the app was tested against the exact version you intend to deploy. When in doubt, build against the lowest version supported by your target runtime.
Local file paths and configuration files
Many applications work locally because they rely on absolute file paths, such as Windows drive letters or developer-specific folders. After upload, those paths no longer exist.
Common examples of local-only assumptions include:
- Hardcoded paths like
C:\Users\... - Reading files from the project root
- Writing to directories without checking permissions
- Loading configuration from a local IDE profile
On a hosting platform, your application should use paths relative to the deployed app, environment variables, or configuration files that are uploaded with the application. If the app needs write access, ensure the target directory is allowed by the hosting account and service limits.
Case sensitivity problems on Linux hosting
A local Windows environment may ignore case differences in filenames, but Linux hosting does not. This can break JSP includes, image references, CSS files, Java class names, and resource loading.
For example, the following may work locally but fail after upload:
Logo.pngreferenced aslogo.pngMyService.javaimported asmyserviceconfig.XMLloaded asconfig.xml
Check every file name, resource path, and package name carefully before deployment.
How to package a Tomcat app correctly before upload
To avoid deployment issues, treat packaging as part of the build process, not as a final step after coding. A reliable deployment package should be self-contained and ready for the target Tomcat environment.
1. Build a proper WAR file
Use your build tool or IDE export function to create a standard WAR archive. Do not upload source folders unless the hosting documentation specifically says that an exploded deployment is supported and recommended.
Verify that the WAR contains:
- Compiled classes
- Required library JARs
- Web resources
- Deployment descriptor if needed
2. Include all required dependencies
Review your Maven, Gradle, or manual library setup. Make sure runtime dependencies are included in the package. If your app uses Spring, Hibernate, JDBC drivers, or other third-party libraries, confirm they are present in the deployed artifact.
3. Match the Java target version
Set the compiler target to the Java version available on the hosting service. This avoids runtime errors caused by newer bytecode. If the hosting panel allows selecting the Java version for the app server, align your build with that choice.
4. Avoid environment-specific settings
Remove assumptions about local machine paths, local databases, and IDE-only variables. Externalize configuration into files or environment values that can be set on the hosting account.
5. Test with the same Tomcat family and Java version
If possible, run a local test using a Tomcat version and Java runtime close to the hosting environment. This reduces surprises after upload.
What to check in Plesk or the hosting control panel
In a managed Java hosting setup, the control panel is often the place where service settings and deployment details are reviewed. If the application fails after upload, check the following:
- Whether the Tomcat service is running
- Whether the correct Java version is selected
- Whether the application was uploaded to the right deployment location
- Whether the service was restarted after upload
- Whether logs show startup or class loading errors
With a solution such as My App Server, the service may be managed independently inside the hosting account. That is useful for Java hosting, JSP hosting, servlet hosting, and private JVM use cases, but the deployment still depends on a clean WAR and compatible runtime settings.
Useful log messages and what they usually mean
When an application works locally but fails on the hosting server, logs are the fastest way to narrow down the cause. Look for these patterns:
ClassNotFoundException— a class or library is missing from the deployment package.NoClassDefFoundError— a class was available at compile time but not at runtime.UnsupportedClassVersionError— compiled with a newer Java version than the server supports.404on JSP or static files — wrong path, wrong case, or incorrect application structure.500 Internal Server Error— application failure during startup or request processing.- Startup timeout — heavy initialization, bad configuration, or missing dependency.
If the hosting platform provides application logs through the control panel, review them immediately after upload and after each change. This is much faster than guessing based on local results.
Practical troubleshooting checklist
Use this checklist when a Tomcat app works locally but fails after upload:
- Confirm the WAR file was built from the latest code.
- Check that all required JAR files are included.
- Verify the WAR structure under
WEB-INF. - Match the Java version used for compilation and runtime.
- Confirm the Tomcat version is compatible with the app.
- Remove hardcoded local file paths.
- Check file and folder names for case sensitivity.
- Review logs for class loading or startup errors.
- Restart the Java service after deploying a new build.
- Test with a minimal version of the application if needed.
Examples of deployment mistakes and fixes
Example 1: Library works in IDE, missing on server
Problem: The app uses a third-party JSON library. It runs locally, but after upload the page fails with a class loading error.
Fix: Add the JAR to the WAR output or configure your build tool so the dependency is packaged in WEB-INF/lib.
Example 2: App built with newer Java
Problem: The app was compiled with Java 21, but the hosting account is running Java 17.
Fix: Rebuild the application targeting Java 17, or change the Java version in the hosting control panel if the service supports it.
Example 3: Works on Windows, fails on Linux
Problem: A JSP includes Header.jsp, but the actual file is named header.jsp.
Fix: Correct the file name and all references so they match exactly.
When to rebuild instead of changing the server
In many cases, the right solution is to fix the application build rather than adjust the hosting environment. If the app depends on IDE-generated paths, local-only resources, or incorrect dependency scopes, changing the server will not solve the root cause.
Rebuild the application if:
- The WAR is incomplete
- Dependencies are missing
- The Java target is wrong
- The project structure is not Tomcat-compatible
- The app relies on files outside the deployed package
Adjust the server only when the application is already packaged correctly and the issue is a clear runtime mismatch.
FAQ
Why does my Tomcat app run in Eclipse or IntelliJ but not after upload?
Because the IDE can supply local libraries, paths, and runtime settings that are not part of the deployed WAR. The hosting server only sees what you upload and what the selected Java and Tomcat runtime provide.
Should I upload source code or a WAR file?
For Tomcat hosting, a WAR file is usually the safest option. It contains the compiled application and dependencies in the expected structure.
What does ClassNotFoundException mean after deployment?
It usually means a dependency or class is missing from the deployed application. Check the WAR contents and build configuration.
Can a Java version difference break deployment?
Yes. If the application was compiled for a newer Java version than the server uses, it may fail at startup with a bytecode compatibility error.
Why do images or JSP includes fail only on the hosting server?
Most often because of case sensitivity, incorrect relative paths, or files that were not included in the uploaded package.
How can My App Server help with this?
It provides a managed way to run your own Tomcat and JVM inside the hosting account, with control over service settings and Java version selection. That makes it easier to match your application requirements, as long as the app is packaged correctly.
Conclusion
If a Tomcat application works locally but fails after upload in the UK hosting environment, the root cause is usually packaging, compatibility, or configuration rather than the hosting platform itself. Focus first on the WAR structure, included libraries, Java version, Tomcat version, file paths, and case-sensitive resource names.
For the most reliable deployment, build a self-contained WAR, confirm the runtime version in the hosting control panel, and review logs after each upload. In a managed Tomcat setup such as My App Server, this approach gives you predictable Java hosting behavior and a much smoother deployment process for JSP, servlet, and WAR-based applications.