When a Java application works on your local machine but fails after upload, the cause is usually not the code itself. In most cases, the problem is a difference between the local runtime and the hosting environment: Java version, build output, file paths, missing libraries, permissions, or the way the application was packaged before deployment.
On a managed hosting platform with Java support, especially when deploying through Plesk and a service such as My App Server, the application must be built in a way that matches the selected Java/Tomcat setup. A project that runs in your IDE may still fail if the uploaded WAR file is incomplete, compiled for a different Java version, or relies on local-only files that are not available on the server.
Most common reasons a Java app works locally but fails after upload
Local environments are often more forgiving. Your IDE may auto-load dependencies, use a different JDK, or keep configuration files outside the project. After upload, the hosting platform only sees the packaged application and the runtime that has been configured in the control panel.
1. Java version mismatch
This is one of the most common causes. A project compiled with Java 17 may not run on a JVM that only supports Java 11. The reverse can also fail if the code uses APIs that are not available in the older runtime.
Typical symptoms include:
- Startup errors after deployment
- Class version errors
- Methods or classes not found at runtime
- Application runs in IDE but fails in Tomcat
Always check the Java version used for:
- Compilation
- Build tool execution
- Tomcat or private JVM runtime on the hosting account
2. Missing dependencies in the build output
Another frequent issue is an incomplete WAR or JAR. In local development, Maven, Gradle, or the IDE may load libraries from your machine. After upload, those libraries must be included correctly in the build output or available to the container in a supported way.
If a library is missing, you may see:
ClassNotFoundExceptionNoClassDefFoundError- Framework startup failures
- Pages that load partially and then error
3. Incorrect packaging for Tomcat
For Java web hosting, the application must be packaged in the format expected by Apache Tomcat. A plain project folder is not enough. For servlet, JSP, and WAR-based deployments, the structure matters.
Common packaging problems include:
- Missing
WEB-INFdirectory - Incorrect
web.xmlplacement, if used - Broken classpath inside the WAR
- Static files placed in the wrong directory
4. Local file paths do not exist on the hosting account
Applications often work locally because they read files from hardcoded paths such as C:\dev\... or a project directory on your computer. After upload, those paths do not exist. On hosted environments, you should use relative paths or configured absolute paths that match the deployment layout.
Check for:
- Hardcoded local paths
- Temporary folders that are not writable
- Configuration files stored outside the deployable package
- Uploads expected in a local project directory
5. File permissions and writable directories
A Java app may need to write logs, upload files, create caches, or store temporary data. On a hosting platform, some directories are read-only, while others are intended for application data. If the app cannot write where it expects to, startup may fail or some features may stop working.
Look for permission-related problems in:
- Log directories
- Temp folders
- Upload directories
- Cache directories
6. Environment variables or JVM options are missing
Local development often includes IDE run configurations, system environment variables, and JVM arguments that are not automatically transferred to hosting. If your application depends on a property such as spring.profiles.active, a database URL, or custom memory settings, those must be defined in the deployed environment.
Examples of runtime settings that may differ:
- JVM memory values
- Active profile settings
- Encoding options
- Custom system properties
How My App Server and Plesk deployment affect Java applications
In a Java hosting environment with My App Server, the application is managed through the control panel and deployed into a Tomcat-based runtime or private JVM, depending on the setup. This is useful for small and medium Java applications, especially when you need direct control over the runtime without managing a separate server manually.
Because the deployment is tied to the selected Java/Tomcat version, build output must match that runtime exactly. A project that behaves correctly on your laptop may still fail if it was built against another Java release or if the WAR file does not contain everything the server expects.
Practical advantages of this setup include:
- Choice of Java version from supported options
- Control of the application server from Plesk
- Dedicated Tomcat or private JVM within the hosting account
- Simple deployment for WAR, JSP, and servlet applications
- Centralized service control and restart options
Step-by-step checklist before uploading your Java app
Before you upload, verify the build and deployment package carefully. This reduces the chance of runtime errors and saves time during troubleshooting.
1. Confirm the target Java version
Check which Java version is selected in the hosting control panel and build your project against the same version, or a compatible lower version if needed. If the runtime is Java 11, compiling with Java 17 features may break deployment.
Use the same version for:
- JDK used in CI/CD or local build
- Target bytecode level
- Runtime on My App Server
2. Build a clean artifact
Always create the artifact from a clean build, not from an old folder or IDE output. A clean build helps ensure that no stale classes or outdated resources are included.
Good practice:
- Run a clean build in Maven or Gradle
- Remove old output before packaging
- Verify the final WAR or JAR content
3. Inspect the package contents
Open the WAR file and check whether the expected classes, libraries, and resources are present. If a dependency is marked as provided or excluded incorrectly, the app may work locally but fail on the server.
Check for:
- Application classes
- Required third-party libraries
- Static assets
- Configuration files needed at runtime
4. Move configuration out of local-only paths
Use environment-based configuration where possible. This is more reliable than hardcoded settings and makes the application easier to deploy in a hosting environment.
Recommended approach:
- Use properties files inside the application when safe
- Store secrets and runtime variables outside source control
- Reference server-side paths that exist in the hosting account
- Avoid absolute local development paths
5. Test with the same runtime locally
If possible, run the application locally with the same major Java version and, if relevant, the same Tomcat version as the hosting platform. This helps identify runtime compatibility problems before upload.
Test areas include:
- Servlet initialization
- JSP compilation
- Database connection
- File upload and file writing
- Application startup without IDE support
Build output issues that often break deployment
When the application runs locally but not after upload, the build output is often the real problem. The source code may be correct, but the packaged files are not suitable for the server.
Dependency scope mistakes
In Maven and Gradle projects, the scope of each dependency matters. A library marked as test-only or provided-only may not be present in the final artifact when the application needs it.
Examples:
- Servlet API used incorrectly in a deployed WAR
- Framework runtime libraries excluded from the package
- JDBC drivers not included where expected
Wrong artifact type
Some projects produce a plain executable JAR, while others are meant to be deployed as a WAR. If your hosting setup is Tomcat-based, a web application usually needs the correct web archive structure.
Use the artifact type that matches the target environment:
- WAR for web applications on Tomcat
- JAR only if the runtime and deployment model support it
- Separate resources if the app expects external configuration
Source resources not copied into the package
Sometimes configuration or template files exist only in the source tree and are not copied into the final build output. In that case the application compiles, but important files are missing after deployment.
Common examples include:
- Property files
- Templates
- XML configuration
- Static assets used by the web app
How to troubleshoot after upload in the hosting control panel
Once the application is uploaded, use the hosting control panel and service tools to narrow down the issue. In a Plesk-based setup, you can usually manage the Java service, restart the app server, and inspect relevant output more quickly than by changing the code blindly.
Check the service status
Make sure the Java service or Tomcat instance is running. If the service fails to start, the issue is often in the deployment package, runtime mismatch, or application initialization.
Review application logs
Logs are the fastest way to identify why a Java app fails after upload. Look for the first error in the startup sequence, not only the last visible exception.
Focus on:
- Startup exceptions
- Missing class errors
- Port or binding issues
- Database connection failures
- File access errors
Restart the app server after changes
After uploading a new build or changing Java settings, restart the service so the runtime loads the updated artifact and configuration. Old classes or cached state can hide the actual result of the new deployment.
Compare local and server runtime settings
Check whether the server is using the same encoding, timezone, memory settings, and Java release level that you used locally. Small differences can cause failures that are not obvious at first glance.
Example scenarios
Scenario 1: Works in IntelliJ, fails with a class version error
Your code compiles and runs in the IDE using Java 17, but the hosting service is set to Java 11. The uploaded application fails immediately because the class files were compiled for a newer bytecode level.
Fix:
- Set the build target to Java 11, or
- Switch the hosting runtime to a compatible Java version if available
Scenario 2: WAR deploys, but pages return 500 errors
The application starts, but requests fail because a library is missing from the final WAR. The IDE loaded it from the local environment, but the uploaded build does not contain it.
Fix:
- Review dependency scopes
- Rebuild the package cleanly
- Confirm the JAR is present inside
WEB-INF/libwhere expected
Scenario 3: File upload works locally, not on hosting
The application writes uploaded files to a hardcoded local folder. On the hosting account, the directory does not exist or is not writable.
Fix:
- Use a server-side writable directory
- Make the path configurable
- Verify permissions in the hosting environment
Best practices for Java, Tomcat, and JSP hosting deployments
To reduce deployment errors, follow a consistent release process for every upload.
- Compile with the same Java major version as the target runtime
- Use clean builds before packaging
- Keep runtime configuration separate from local development settings
- Include all required libraries in the final artifact
- Test startup without relying on IDE features
- Check logs immediately after deployment
- Restart the Tomcat or Java service after changing the build
For hosted Java applications, this discipline is especially important because the server only runs what you upload. Unlike local development, the control panel does not guess which dependencies or paths you intended to use.
When to use My App Server for this type of deployment
My App Server is a practical choice when you need Java hosting with direct control in Plesk, your application is based on Tomcat, and you want to manage a private JVM or a dedicated app server instance within your hosting account. It is well suited for WAR-based applications, JSP sites, servlet projects, and smaller Java services that do not require a complex enterprise cluster.
This type of hosting is a good fit when you want:
- Simple Java deployment through the control panel
- Selectable Java versions
- Tomcat management without manual server setup
- A separate runtime for your application
- Reliable hosting for small and medium Java projects
FAQ
Why does my Java app run on my computer but not on the hosting server?
Usually because the server uses a different Java version, the build output is incomplete, or the application depends on local files and settings that are not present after upload.
What is the first thing I should check after a failed upload?
Check the Java version, then review the logs for the first startup error. In many cases this points directly to a missing library, class version mismatch, or file path problem.
Do I need to upload source code or a WAR file?
For Tomcat-based hosting, you normally upload the final deployable artifact, usually a WAR file. Source code alone is not enough unless your workflow explicitly supports server-side build steps.
Can a dependency work locally but still be missing on the server?
Yes. Your IDE may load libraries from the local environment, but the server only uses what is included in the uploaded package or available in the configured runtime.
How do I avoid path-related errors?
Avoid hardcoded local paths and use configurable server-side paths instead. Test file access with the same directory structure you will use after deployment.
Does Tomcat automatically fix build problems?
No. Tomcat runs the application, but it cannot repair an incomplete WAR, incompatible Java bytecode, or missing dependencies. The package must be correct before upload.
Conclusion
If a Java application works locally but fails after upload, the cause is usually a deployment mismatch rather than a code defect. Start by checking the Java version, build output, packaged dependencies, and server-side paths. Then use the hosting control panel, service controls, and logs to identify what changed between your local machine and the hosted environment.
In a Plesk-based Java hosting setup with My App Server, the most reliable approach is to build a clean WAR or compatible artifact, match the Java runtime, and verify that the application does not depend on local-only configuration. This is the safest way to deploy Java, Tomcat, JSP, and servlet applications on shared hosting with a private JVM or dedicated app server instance.