If you are deploying a Java application on a managed hosting account with Plesk and My App Server, the best deploy path is usually the application’s web root folder inside your Java hosting service, not the general public web root used by a PHP or static site. In most cases, the correct path is the one mapped to your Tomcat application context, where your WAR file, exploded application, JSP files, and related resources are managed by the Java service rather than by Apache alone.
The exact deploy path depends on how your application is set up, but the practical rule is simple: deploy Java web applications into the folder used by your Tomcat instance or app server service, then let the service handle the runtime. That gives you cleaner updates, easier version control, and fewer permission issues than placing Java files directly into a generic FTP directory.
What a deploy path means for Java hosting
In Java hosting, the deploy path is the location where the application package is uploaded or unpacked so the application server can run it. For Tomcat-based hosting, this is usually a web application directory tied to a specific context path. The deploy path may contain:
- WAR files for deployment
- Exploded application folders
- JSP pages and static assets
- Configuration files used by the app
- Upload folders or generated content, if your application needs them
With a setup like My App Server in Plesk, the deploy path is not just a file storage location. It is part of the service configuration. The Java runtime, Apache Tomcat, and the service control tools all need to point to the same application location so the app starts correctly.
Best practice: use the Tomcat application directory, not the generic site root
For most Java web applications, the recommended deploy path is the Tomcat app directory associated with your service. This is the folder where Tomcat expects to find the application for a given context.
Do not assume that the same folder used for an HTML or PHP website is the right place for Java code. A Java application often needs:
- its own Java runtime or private JVM
- Tomcat-managed deployment
- service restart after updates
- specific file permissions
- separate paths for logs and temporary files
If you upload a WAR file into the wrong directory, the application may not deploy, may fail to start, or may conflict with Apache document root settings.
Typical deploy path choices in Plesk Java hosting
The right deploy path usually falls into one of these patterns:
1. Tomcat webapps directory
This is the most common and familiar Tomcat deploy path. In a standard Tomcat setup, applications are deployed in the webapps directory. A WAR file placed there can be auto-deployed, or the application can be unpacked into a context folder.
Use this path when:
- you are deploying a WAR file
- your application is built for Tomcat
- you want standard servlet/JSP deployment behavior
2. A custom application directory managed by My App Server
With managed hosting and a Plesk extension like My App Server, you may have a dedicated path chosen by the control panel or set during service creation. This path can point to a custom folder for the app server instance, with separate folders for app files, logs, and temporary data.
Use this path when:
- the service was created with a custom app server layout
- you installed a specific Java or Tomcat version through the panel
- your hosting provider expects deployments to be managed from a named service path
3. The context-specific folder for a single application
Some hosting accounts are configured for one Java application per service. In that case, the deploy path is often a single folder tied to the domain or subdomain. The application may run directly from that location, or it may be copied into Tomcat’s runtime structure during deployment.
This is common for:
- single-site JSP applications
- small servlet-based tools
- private JVM deployments with one main app
How to identify the correct deploy path in your account
If you are not sure which path to use, check the service details in Plesk first. In a managed Java hosting setup, the control panel usually shows the application path, the service name, and sometimes the active Tomcat instance or Java version.
Look for:
- the app server service name
- the configured document or deploy root
- the Tomcat version selected for the service
- the Java version assigned to the instance
- any deployment notes from the hosting provider
If the panel includes a “service control” section, that is often where you confirm whether the application is started, stopped, or restarted after a deploy. If files are uploaded but the app is not visible, the path may be wrong or the service may need a restart.
Recommended deploy paths by application type
WAR applications
For a WAR package, deploy it to the Tomcat webapps directory or the app server’s equivalent deploy folder. In many cases, the WAR filename becomes the context path.
Example:
- myapp.war deployed to the Tomcat app folder
- application available under /myapp
If you want the app to run at the root URL, the deployment may need a specific context configuration rather than just a different file name.
Exploded web applications
For an exploded deployment, upload the full folder structure into the Tomcat app directory. This is useful for incremental updates during development or for applications that are easier to manage as files rather than as a packaged WAR.
Make sure the folder contains the expected structure, such as:
- WEB-INF/
- classes/
- lib/
- JSP files
- static assets
JSP and servlet projects
JSP hosting and servlet hosting are usually handled best by deploying the project into the Tomcat application path rather than the site’s static web folder. JSP files must be processed by the Java runtime, not served as plain files.
For these applications, the deploy path should point to:
- the app server’s active web application folder
- a Tomcat context directory
- the managed service path used by the Plesk extension
How to deploy a Java application in Plesk
The exact screen layout may vary, but the workflow is usually similar.
Step 1: Check the active Java service
Open your Plesk panel and locate the Java hosting service managed by My App Server. Confirm the service is running and note which Java and Tomcat versions are selected.
Step 2: Identify the app directory
Find the deployment path shown for the service. This may be the app server folder, the Tomcat webapps folder, or a custom path linked to your domain or subdomain.
Step 3: Upload the application package
Use FTP, the file manager, or the panel’s deployment tools to upload your WAR file or exploded application into the correct folder.
Important points:
- keep the package name simple
- avoid spaces and special characters
- do not upload Java app files into unrelated site folders
- preserve the folder structure for exploded apps
Step 4: Set the correct permissions
The app server must be able to read the application files and write to any required temporary or upload directories. If permissions are too strict, the app may fail at startup or during runtime.
Check that:
- the Tomcat process can read the deploy path
- write access is allowed where needed
- temporary folders are available for runtime use
Step 5: Restart or reload the service
After deployment, restart or reload the Java service if required. Some Tomcat setups auto-deploy changes, but managed hosting often benefits from a controlled restart so the new version is loaded cleanly.
Step 6: Test the application URL
Open the domain or context path in your browser and test the application. If it does not load correctly, verify the deploy path, logs, and service status.
Common mistakes when choosing a deploy path
Many Java deployment problems are caused by choosing the wrong folder. These are the most common issues:
- Using the public website root for Java code. This works poorly for Tomcat applications and can bypass the app server.
- Uploading a WAR to the wrong directory. The file may sit there unused and never deploy.
- Mixing static and Java application files. Keep app server files separate from unrelated site content.
- Ignoring service configuration. The path must match the Java service that is actually running.
- Forgetting to restart after changes. Some deployments need a reload before the new version appears.
Where Apache fits in this setup
In a hosting environment that uses Apache together with Tomcat, Apache often serves as the front-end web server, while Tomcat handles the Java application. That means the deploy path still matters inside the Tomcat service even if Apache is serving the domain.
In practical terms:
- Apache may route requests to the Java app
- Tomcat runs the JSP/servlet application
- the deploy path must match the Tomcat context
- static files may be handled separately, depending on the setup
If your app uses both static content and Java processing, be clear about which files belong to the web application package and which belong to the Apache-facing site structure.
Best practices for file management and deploy paths
To keep Java hosting manageable, use a consistent deployment approach.
- Use one directory for each application instance.
- Keep WAR files in a dedicated deploy folder.
- Use versioned backups before replacing production files.
- Document the active context path and Java version.
- Keep logs separate from the application code.
- Test deployments on a staging path when possible.
For managed hosting, it is also a good idea to keep a note of:
- the deployed app name
- the exact folder used
- the Tomcat version in use
- the Java runtime version
- the last successful deploy date
Examples of suitable deploy paths
The actual path names depend on your account structure, but these examples show the kind of folder you should expect to use:
/var/www/vhosts/example.com/tomcat/webapps//var/www/vhosts/example.com/appserver/myapp//home/example/httpdocs/app/when the hosting service maps it to Java deployment/usr/local/tomcat/webapps/in a standard Tomcat layout
The correct path in your service may look different, but it should follow the same principle: the deploy location must be the one linked to the Java runtime and the app server, not just any folder accessible by FTP.
Troubleshooting if the app does not deploy
If your Java application does not appear after upload, check the following:
- Is the file in the correct deploy path?
- Is the service running in Plesk?
- Is the Java version compatible with the application?
- Is the Tomcat version the one your app expects?
- Are file permissions correct?
- Did you restart or reload the service?
- Are there errors in the app server logs?
If the app deploys but returns an error, the issue may be in the application package itself, not only in the path. Common causes include missing libraries, invalid context configuration, or incompatible Java code.
When to use a custom app server path
A custom app server path is useful when your hosting setup needs a more controlled Java environment. With My App Server, this can mean a dedicated service instance with its own Java runtime, deployment folder, and control options inside Plesk.
This approach is especially useful for:
- small and medium Java applications
- applications that need a private JVM
- Tomcat-based web apps with one clear deploy folder
- projects where the control panel should manage the service lifecycle
It is less about enterprise-scale clustering and more about practical, reliable application hosting with clear file paths and service control.
FAQ
What deploy path should I use for a Java application in Plesk?
Use the Tomcat application directory or the deploy path assigned by your My App Server service. Do not use a random FTP folder unless it is explicitly mapped to the Java application.
Should I upload my WAR file to httpdocs?
Usually no, unless your hosting provider has specifically configured that folder to act as the Java deploy root. In most Java hosting setups, the WAR belongs in the Tomcat or app server directory.
Can I deploy JSP files directly?
Yes, if they are part of an exploded web application placed in the correct Tomcat application folder. JSP files need to be handled by the Java runtime, not just stored as static files.
Do I need to restart the service after uploading files?
Often yes. Some Tomcat services auto-detect changes, but a restart or reload is a safer way to make sure the new application version is active.
What if my app has its own private JVM?
Then use the deploy path associated with that specific JVM and service instance. The key is to keep the application files and the runtime tied together inside the managed hosting setup.
How do I know if the folder is correct?
If the service starts, the app loads at the expected URL, and the logs show no deploy errors, the folder is likely correct. If the app does not appear, check the service configuration and logs first.
Conclusion
For a Java application hosted with Plesk and My App Server, the safest deploy path is the one connected to your Tomcat or app server service. In practice, that means using the managed Java deployment folder rather than the general site root. This keeps your WAR files, JSP pages, servlets, and runtime files aligned with the Java service that actually runs the application.
If you follow the service path shown in the control panel, verify permissions, and restart the app server when needed, deployment becomes much more predictable. That is the best approach for Java hosting, Tomcat hosting, and private JVM applications in a managed shared hosting environment.