If a Tomcat deployment fails on shared hosting, the cause is usually one of a few common issues: the WAR file was uploaded in the wrong place, the application is using an unsupported Java version, the app expects a different Tomcat version, or the deployment was interrupted by a startup error in WEB-INF or context.xml. In a managed hosting environment with Plesk and a Java hosting extension such as My App Server, you can usually narrow down the problem quickly by checking the service status, deployment logs, and application-specific configuration.
This article explains how to diagnose and fix a failed Tomcat deployment on shared hosting in the UK, with practical steps for Plesk-based Java hosting, private JVM setups, JSP/Servlet applications, and WAR deployments.
Why Tomcat deployments fail on shared hosting
On shared hosting, Tomcat runs inside a controlled environment with limits on ports, memory, file access, and service management. That is normal and helps keep the platform stable, but it also means a deployment that works on a local machine or a dedicated server may fail if it relies on unavailable system-level access.
The most common reasons are:
- Incorrect WAR packaging or broken application structure
- Unsupported Java version or Tomcat version
- Missing dependencies inside the application archive
- Port conflicts or service startup failures
- File permission issues in the application directory
- Memory limits reached during startup
- Configuration errors in
web.xml,context.xml, or Spring/Framework settings - Application code that expects write access outside the hosting account
With My App Server, the deployment process is designed for practical Java hosting needs: install Tomcat or a private JVM through Plesk, choose an available Java version, and manage the service without requiring root access. That makes troubleshooting simpler, but the application still needs to be packaged correctly.
Step 1: Check whether the Tomcat service is running
Before changing the application, confirm that the Tomcat service or Java application server is actually running. If the service is stopped, the deployment may appear to have failed even though the real issue is startup, not the WAR file itself.
What to check in Plesk
- Open the hosting control panel and go to the Java hosting or My App Server section.
- Check the service status.
- Look for options such as start, stop, restart, or service control.
- If the service is not running, try restarting it.
If the restart fails, the problem is likely in the application or the Java/Tomcat configuration. If the service starts successfully but the app still does not load, continue with deployment checks.
Step 2: Confirm that the WAR file is valid
A corrupted or incorrectly built WAR is one of the most frequent causes of failed Tomcat deployment. The archive may upload correctly, but Tomcat cannot expand or start it because the application structure is invalid.
Check the following
- The file is a real
.wararchive, not a renamed ZIP file - The archive contains a proper Java web application structure
WEB-INFexistsWEB-INF/web.xmlis present if the application requires it- Class files and libraries are placed in the correct folders
If you built the application locally, rebuild the WAR and test it again. If possible, deploy a known-good sample WAR to verify that the Tomcat environment itself is working. That helps separate platform issues from application issues.
Step 3: Review the deployment logs
The most useful information is usually in the logs. A failed Tomcat deployment often produces a clear error message such as a missing class, invalid descriptor, or unsupported Java version.
Where to look
- Tomcat or application server logs in the hosting control panel
- Plesk Java hosting logs, if available
- Application-specific logs created by the framework
- Startup logs for the private JVM or service instance
Look for messages such as:
ClassNotFoundExceptionNoClassDefFoundErrorUnsupported major.minor versionSEVERE: Error starting web applicationPort already in usePermission denied
These messages normally point directly to the cause. If the log shows the same error during every restart, fix that problem before trying to redeploy again.
Step 4: Match the Java version to the application
Many deployment failures happen because the application was compiled for a newer Java version than the one selected in hosting. The reverse can also happen: the app may depend on features that are no longer compatible with older runtime versions.
Typical mismatch examples
- Application built for Java 17 but hosting uses Java 11
- Application requires Jakarta EE namespace changes but was deployed to older servlet APIs
- App uses libraries compiled for a newer bytecode level than the JVM supports
With My App Server, one of the practical advantages is the ability to choose from available Java versions or install a ready Tomcat version through the control panel. If the app fails after a Java update or version switch, try selecting the version it was originally built for.
How to test this safely
- Check the app documentation for the required Java release
- Compare the build target from your development environment
- Switch to the matching Java version in Plesk
- Restart the service and redeploy the WAR
If the application works only on one Java version, record that version in your deployment notes so future updates do not break the site.
Step 5: Verify Tomcat compatibility
Java version is not the only compatibility factor. Tomcat itself has different major releases, and some applications depend on specific servlet API behavior or deployment descriptors.
Watch for these signs
- The app starts locally on an older Tomcat release but fails on the hosting platform
- Errors mention servlet API or JSP compilation issues
- Frameworks such as Spring or JSF report missing classes at startup
If your hosting plan provides more than one Tomcat version, use the one recommended by the application. If the platform allows installing another supported version, test that version before changing code. This is especially helpful for legacy JSP or servlet applications.
Step 6: Check application packaging and folder structure
Even when the WAR is valid, the internal structure can still cause a deployment failure if files are misplaced. Tomcat expects a standard web application layout.
Common structure issues
- JAR files placed outside
WEB-INF/lib - Compiled classes not stored under
WEB-INF/classes - Configuration files located in the wrong directory
- Duplicate libraries causing class conflicts
- Old unpacked content left behind from a previous deployment
If the application was previously deployed and then updated, remove the old deployment before uploading the new WAR. Stale files can keep old classes, old JSPs, or old settings in place and make the new deployment fail in confusing ways.
Step 7: Check file permissions and writable directories
Tomcat applications often need to write logs, upload files, create temporary data, or generate cache files. On shared hosting, only the account’s allowed directories should be used, and the application must not expect unrestricted system access.
Common permission-related problems
- The app tries to write to a directory outside the hosting account
tmpor cache folders are not writable- The deployment directory has the wrong ownership or permissions
- External storage paths are hardcoded from a local environment
Use only directories that are writable by the hosting account. If the app needs a temporary location, configure it explicitly inside the account space. Do not rely on local paths such as C:\ or server-specific Unix paths that are not available in shared hosting.
Step 8: Review memory usage and startup limits
Some deployments fail because the application is too heavy for the current memory allocation during startup. This is common with frameworks that load many classes, large Spring applications, or apps that unpack large resources on boot.
Symptoms of memory-related failures
- Tomcat starts and then stops during deployment
- Logs show
OutOfMemoryError - Startup takes too long and ends in a timeout
- Deployments fail after a code or library update
If your hosting plan allows it, review the JVM settings and increase memory only within the documented limits. In managed shared hosting, it is important to stay within the service’s resource boundaries. A small or medium Java web application usually works well, but very large enterprise-style deployments are not the target use case.
Step 9: Look for conflicts with context path or application name
A failed deployment sometimes happens because the application is trying to deploy under a path that already exists or conflicts with another app.
What to verify
- There is no older deployment using the same context path
- The WAR filename matches the intended application URL path
- No manual context configuration points to a broken directory
- The same app is not already deployed twice
If the platform deploys applications based on the WAR name, rename the archive carefully. A filename change can affect the URL path. If needed, clear the old deployment, remove stale unpacked files, and deploy again with the desired name.
Step 10: Test with a minimal sample application
If you are not sure whether the problem is in Tomcat or in the application, deploy a very simple test WAR. This is one of the fastest ways to isolate the failure.
Why this helps
- If the sample app works, the hosting platform is fine
- If the sample app also fails, the issue is in Tomcat, Java, or service configuration
- If only your app fails, focus on packaging, dependencies, and code
A minimal JSP or servlet test app can confirm that the service can start, compile JSP pages, and serve HTTP traffic correctly.
Step 11: Rebuild the deployment cleanly
Once you identify a likely cause, remove all old deployment artifacts before trying again. Partial redeployments are a common reason for repeated failures.
Clean redeploy checklist
- Stop the Tomcat service if needed
- Remove the old WAR and unpacked application folder
- Delete cached or temporary files generated by the old app
- Upload the corrected WAR
- Start or restart the service
- Check the logs immediately after startup
This process helps avoid issues caused by leftover class files, stale JSP compilation, and old configuration values.
Common error messages and what they usually mean
ClassNotFoundException or NoClassDefFoundError
A dependency is missing from WEB-INF/lib, or the application expects a library that is not bundled with the WAR. Rebuild the package and make sure all required JAR files are included.
Unsupported major.minor version
The application was compiled for a newer Java version than the one configured on the hosting account. Switch to a matching Java version or rebuild the app for the supported runtime.
Port already in use
Another process is already using the port the application wants to bind to. In shared hosting, the application should usually not try to open arbitrary external ports. Review the app configuration and use the standard Tomcat setup.
Permission denied
The app is trying to write to a protected path. Redirect logs, uploads, or temp files to a directory inside the hosting account.
Error starting web application
This is a general startup failure. The detailed cause is usually a few lines earlier in the log. Check the full stack trace, not only the final line.
How My App Server helps with Tomcat deployment
In a Plesk-based hosting environment, My App Server is designed to make Java hosting more practical on shared hosting accounts. For Tomcat deployment troubleshooting, the most useful features are:
- Control from the hosting panel without direct server access
- Ability to install and manage Apache Tomcat from the account
- Support for multiple Java versions, where available
- Private JVM-style application control inside the hosting account
- Simple deployment of WAR, JSP, and servlet applications
This setup is suitable for small and medium Java web applications that need a clean, manageable hosting environment. It is not meant to replace specialised enterprise clustering or complex high-availability application server management.
Recommended troubleshooting flow
If you need a quick order of operations, use this sequence:
- Check that the Tomcat service is running
- Review the deployment logs
- Confirm the WAR is valid
- Match the Java version to the app
- Verify Tomcat compatibility
- Check permissions and writable paths
- Look for leftover old deployment files
- Test with a minimal sample WAR
- Redeploy cleanly after the fix
Following this order saves time because it separates platform-level startup problems from application packaging issues.
FAQ
Why does my Tomcat app deploy locally but fail on shared hosting?
Local environments often allow different Java versions, file paths, ports, and memory settings. Shared hosting is more controlled, so the app must match the available Java/Tomcat version and use account-allowed paths only.
Can I deploy any Java web application on shared hosting?
Only applications that fit the available runtime, resource limits, and deployment model. Small and medium WAR-based Java apps usually work well. Very heavy enterprise setups are typically not a good fit for shared hosting.
What should I check first if the deployment fails immediately?
Start with the logs and the Java version. Immediate startup failures are often caused by version mismatch, missing classes, or invalid application packaging.
Do I need a special folder structure for JSP and servlet apps?
Yes. The application must follow the standard web app layout, with compiled classes and libraries in the correct locations. A broken structure can stop Tomcat from deploying the app.
Why does the app stop after restart but worked before?
This often happens after a Java update, a changed configuration file, a damaged WAR upload, or leftover files from an older deployment. A clean redeploy usually helps identify the cause.
Can file permissions break a Tomcat deployment?
Yes. If the application cannot write logs, cache files, uploads, or temporary files, startup may fail or the app may crash after launch.
Conclusion
A failed Tomcat deployment on shared hosting is usually fixable once you identify whether the issue is in the WAR package, the Java version, Tomcat compatibility, file permissions, or service startup. In a managed Plesk environment with My App Server, you can usually resolve the problem without server-level access by checking the service status, reviewing logs, matching the runtime version, and redeploying the application cleanly.
If the app still fails after these checks, the most useful next step is to collect the exact error from the deployment log and compare it with the application’s runtime requirements. In most cases, that will point directly to the fix.