The correct deploy path for a Java application depends on how your hosting account is set up and whether your application runs as a standalone Java process, a WAR package, or a Tomcat-based web app. In a managed hosting environment with Plesk and My App Server, the most important rule is simple: deploy into the application directory that is assigned to your domain or subdomain, not into a random web root unless the service specifically expects it.
For Java hosting, the deploy path is usually the folder where Tomcat or the private JVM reads application files, configuration, and web content. If you upload the package to the wrong location, the application may not start, the context path may not resolve correctly, or the server may continue serving an older version of your app.
What the deploy path means in a Java hosting setup
In Java hosting, “deploy path” refers to the directory where your application is uploaded, unpacked, or mounted so that Tomcat or the Java runtime can run it. This is not always the same as the public document root used by static websites. For Java applications, the deploy path can be one of the following:
- a Tomcat web application directory for WAR deployment
- a private application folder used by a custom Java service
- a path configured in Plesk/My App Server for a specific domain or subdomain
- a directory for application resources, logs, or startup scripts
With ITA’s My App Server, the deploy path is typically tied to the service configuration in Plesk. That means the application should be placed where the service expects it, so the control panel can manage startup, shutdown, Java version selection, and domain routing correctly.
The safest default: use the application path assigned in Plesk
If your hosting plan includes My App Server, the safest choice is to use the deploy path shown in the Plesk extension or in the service details. This path is designed for the specific Java app server instance connected to your account. It usually corresponds to the project or application directory created during installation.
In practice, this gives you a few benefits:
- the app is deployed in the same place that the service monitors
- updates are easier to apply without affecting unrelated files
- your Java version and Tomcat instance remain aligned with the app
- file permissions and ownership are easier to manage
If you are unsure, do not guess. Check the My App Server settings in Plesk and use the directory shown there. This is especially important when you are managing JSP hosting, servlet hosting, or a private JVM inside a shared hosting account.
Common deploy paths for Java applications
1. Tomcat webapp deployment directory
If your application is a WAR file and runs on Apache Tomcat, the deploy path is usually the Tomcat webapps location or a service-specific folder mapped to it. In many setups, Tomcat automatically deploys applications placed in its web application directory.
Use this option when:
- you are deploying a WAR archive
- the app is designed for Tomcat
- you want the server to unpack and run the application automatically
For shared hosting with My App Server, you may not access the raw Tomcat installation directly, but the same principle applies: deploy into the application folder connected to that Tomcat instance.
2. Domain or subdomain application root
Some Java hosting setups map a domain or subdomain directly to an application root. In that case, the deploy path is the directory linked to that hostname in Plesk. Your Java app files, static assets, and configuration may all live there, while the control panel routes requests to the correct runtime.
Use this option when:
- your application is assigned to a specific domain or subdomain
- you need clean separation between multiple apps
- the control panel defines a document root or app root for the service
3. Private JVM application directory
If your hosting account includes a private JVM, the deploy path may be a dedicated folder for the Java process. This directory may contain the application JARs, class files, resources, startup scripts, or supporting libraries. The exact structure depends on how the service was created.
Use this option when:
- your app runs as a standalone Java process
- you manage startup parameters and memory settings
- the app does not use a standard WAR deployment
How to choose the correct deploy path
To avoid deployment problems, choose the path based on the application type and the service configuration. The correct deploy path is the one that matches how the Java service is meant to run.
If you are deploying a WAR file
Upload the WAR to the Tomcat-assigned application path or to the webapps-equivalent directory exposed by My App Server. If your control panel offers an install or deploy button, prefer that method because it registers the application with the service.
If you are deploying JSP or servlet source files
Place the files in the application directory used by the Tomcat instance. Do not upload JSP files into a standard static website folder unless your hosting configuration explicitly processes them through Tomcat. A JSP file outside the Java app root will usually be treated as plain text or not be executed at all.
If you are deploying a JAR-based app
Use the directory defined for the private JVM or custom Java service. A JAR application often needs a launch command, JVM arguments, and a working directory. In this case, the deploy path is not just where the file lives; it is also the folder the service uses when starting the process.
If you are using a custom app server configuration
When you configure a custom Java or Tomcat instance, the deploy path should follow the paths set during service creation. This keeps the application aligned with the selected Java version, port mapping, and runtime options. Changing the directory without updating the service configuration may break the deployment.
Recommended deployment workflow in Plesk
A practical deployment workflow for Java hosting usually looks like this:
- Open Plesk and go to the My App Server extension.
- Select the relevant domain, subdomain, or app service.
- Check the assigned application path or deploy path.
- Confirm the Java version and Tomcat instance used by the service.
- Upload the application package to the expected directory.
- Restart or reload the service if required.
- Verify the application in the browser and check logs if needed.
If your package contains a WAR file, deploy it through the interface if available. If your service expects extracted files, make sure the folder structure matches the app server’s requirements. A correct folder name, correct casing, and correct permissions are all important in Linux-based hosting environments.
Folder structure tips for Java deploy paths
Even when the path is correct, the internal structure of your deployment matters. A typical Java web app may include:
- application code or WAR contents
- WEB-INF for configuration and protected resources
- static assets such as CSS, JavaScript, and images
- application properties or environment-specific config files
- logs or temporary files, if the service writes them locally
Keep the deploy path clean and avoid mixing unrelated files. Do not place backups, old archives, or test folders inside the active application directory unless you know the runtime will ignore them. This helps with faster troubleshooting and reduces the risk of deploying the wrong version.
What not to do when choosing a deploy path
- Do not upload your Java app into a generic public folder if the service uses a separate app root.
- Do not place a WAR file in a folder that is not monitored by Tomcat.
- Do not change the path manually without checking the Plesk service settings.
- Do not assume that the web root for PHP or static sites is the same as the Java deploy path.
- Do not mix production files with temporary build output.
These mistakes can lead to deployment failures, 404 errors, context path issues, or an app that starts with outdated content. In managed hosting, the platform is designed to simplify deployment, so it is better to follow the service-defined path than to improvise.
How deploy paths work with Apache Tomcat
Apache Tomcat uses application deployment directories and context mapping to serve Java web applications. In a standard setup, placing a WAR file or an extracted app in the correct directory allows Tomcat to deploy it automatically. In a hosting platform with My App Server, that logic is typically wrapped in the control panel so you can manage the app without editing Tomcat internals directly.
When using Tomcat hosting through Plesk, the deploy path should match the Tomcat instance connected to the domain. This makes it easier to:
- switch Java versions when needed
- restart the service from the control panel
- manage multiple applications on one account
- separate one app from another on different subdomains
If your application is meant to be served from the root of a domain, the deploy path may be mapped accordingly. If it should run under a subpath, such as /app or /demo, the service may use a context configuration rather than a plain directory name alone.
File permissions and ownership
Even the correct deploy path will not work properly if file permissions are wrong. On hosted Java environments, the application files should be readable by the service and writable only where necessary. Logs, cache directories, and upload folders may need write access, while application classes and configuration should usually remain protected.
When uploading via FTP or the file manager, make sure:
- the files are owned by the hosting account user
- the Java service can read the deployment files
- only required directories are writable
- permissions are not too open for sensitive files
If the app fails after upload, permissions are one of the first things to check, along with the deploy path and Java service status.
Troubleshooting if the application does not start
If you are sure the files are uploaded but the app still does not run, check the following:
- Is the application in the correct deploy path?
- Is the selected Java version compatible with the app?
- Is the Tomcat or private JVM service running?
- Did the deployment complete successfully in Plesk?
- Are there errors in the application or server logs?
- Is the context path correct for the domain or subdomain?
In many cases, the issue is not the application itself but the location where it was uploaded. A small path mismatch can stop the deployment from being recognized by the runtime.
Best practices for deploying Java applications on managed hosting
- Use the path assigned by Plesk or My App Server.
- Keep one application per service or clearly separated directory.
- Match the deploy method to the app type: WAR, JAR, JSP, or servlet-based app.
- Verify Java version compatibility before upload.
- Restart or reload the service after major changes.
- Keep a clean directory structure and remove old artifacts.
- Test the app after deployment and check logs immediately if something fails.
These habits reduce downtime and make hosted Java applications easier to maintain, especially in shared hosting environments where the platform manages the runtime for you.
FAQ
What deploy path should I use for a Java WAR file?
Use the application directory assigned to your Tomcat instance or the deploy path shown in Plesk/My App Server. If the platform offers a deploy button, use that first.
Can I use my website document root for a Java app?
Only if your hosting setup explicitly maps the Java service to that path. In most cases, Java apps should be deployed to the application path defined by the service, not a generic static web root.
Where should JSP files be uploaded?
Upload JSP files into the Java application directory used by Tomcat, not into a normal HTML folder unless that folder is served through the Java runtime.
What if I have a private JVM instead of Tomcat?
Use the service directory defined for that JVM instance. The deploy path is the folder that contains the application files and the startup configuration for the process.
Can I change the deploy path later?
Usually yes, but only if you update the app server configuration in Plesk as well. If the control panel still points to the old folder, the service may not find your new files.
Why does my application show an old version after upload?
The most common reasons are uploading to the wrong path, forgetting to redeploy or restart the service, or leaving old files in the active application directory.
Conclusion
The best deploy path for a Java application is the one assigned by your hosting platform, Plesk extension, or Tomcat service configuration. For ITA Java hosting with My App Server, that usually means deploying into the application directory connected to your domain or subdomain, so the managed Tomcat or private JVM can read and run the app correctly.
If you are deploying a WAR, JAR, JSP, or servlet-based application, always match the file location to the service type. When in doubt, check the My App Server settings first and use the path shown there. That approach gives you the most reliable deployment, simpler maintenance, and fewer errors during updates.