When you deploy a Tomcat application on a hosting platform that uses Plesk and a Java extension such as My App Server, the correct deploy path depends on how the application is packaged and how the service is configured. In most cases, the safest approach is to deploy to the Tomcat webapps directory associated with your application server instance, or to the path defined in your Plesk extension settings. If you upload the wrong file to the wrong folder, Tomcat may not detect the application, may fail to start it, or may deploy it under an unexpected context path.
For standard WAR-based deployments, the deploy path is usually the Tomcat webapps directory. For unpacked applications, it is the application root inside that same Tomcat instance. If you are using a managed hosting control panel, you should always follow the exact path shown in your service panel rather than guessing from a default Tomcat installation. In a shared hosting environment, the Tomcat instance is often isolated per account, so the deploy path is specific to your service and Java version.
What the deploy path means in Tomcat hosting
The deploy path is the location where Tomcat expects to find an application package or application files. Tomcat uses this location to load the app, map it to a context, and start the servlet container. In practical hosting terms, this is the folder where you upload your WAR file or the directory that contains the extracted application.
On a hosting platform with Plesk integration, the deploy path is often linked to:
- the Tomcat instance assigned to your domain or subscription;
- the Java version selected for that service;
- the application context configured in the control panel;
- the internal folder structure created by the My App Server extension.
This means there is no single universal path that fits every account. The correct answer is always the one tied to your current Tomcat service.
Default deploy path for a Tomcat application
In classic Tomcat deployments, the default application deployment directory is usually named webapps. Tomcat monitors that folder and auto-deploys any WAR file placed there, or any unpacked application directory found in it. If the instance is running with auto-deploy enabled, Tomcat can start the application automatically after upload or restart.
Typical deployment patterns include:
- WAR deployment: upload
yourapp.warinto the Tomcat webapps folder. - Exploded deployment: upload the application files into a directory such as
yourapp/inside webapps. - Root deployment: use
ROOT.waror the ROOT application folder if you want the app to open at the domain root.
However, on managed hosting the internal path may not be identical to a self-managed Tomcat installation. The control panel may expose a service-specific deploy location or handle the deployment automatically after you upload the package through the panel.
How to choose the right deploy path in Plesk
If your hosting account includes a Tomcat service managed through Plesk and My App Server, use the path shown in the Java application settings for that service. This is the most reliable method because the platform may create a private JVM, a dedicated Tomcat instance, or a custom file structure for the subscription.
Use the path assigned to your application server instance
Each Tomcat service should have its own deployment root. The assigned path is the one where Tomcat reads application packages and related configuration files. Do not upload files into a general website folder unless the service documentation explicitly says so.
Check the context path and app root
Tomcat deployment is not only about the file location. It is also about the context path. For example, if you deploy shop.war, the application may be available at /shop. If you need the site to open at the domain root, deploy as ROOT.war or configure the root context in the panel.
Follow the My App Server configuration
With My App Server, the deploy path may be linked to the Java service management options in Plesk. The control panel can define:
- which Tomcat version is active;
- which JVM is used;
- where the application package should be uploaded;
- whether the app is deployed automatically or manually;
- how the service is started, stopped, or restarted.
Always use that configured location rather than a generic FTP folder.
WAR file deployment path
For most Tomcat hosting users, the easiest deployment method is uploading a WAR file to the Tomcat deploy path. A WAR file is a compressed Java web application archive that Tomcat can unpack and run.
Use this method when:
- your application is packaged as a WAR;
- you want a simple upload-based deployment;
- your hosting platform supports auto-deploy or restart-based deployment;
- you are deploying JSP, servlet, or standard Java web app content.
Recommended steps:
- Build or obtain the WAR file from your application project.
- Open your Plesk or file manager access for the relevant Tomcat service.
- Upload the WAR file to the Tomcat webapps directory or the deploy path shown in the panel.
- Wait for auto-deployment or restart the service if required.
- Test the application URL and confirm that the context path matches the package name.
If the application does not appear after upload, check whether the service requires manual deployment or a service restart.
Exploded application deployment path
Some Tomcat applications are deployed as extracted folders rather than as WAR files. This is often called an exploded deployment. In this case, the deploy path is a directory that contains the application structure, including WEB-INF, JSP files, classes, libraries, and static resources.
Use an exploded deployment when:
- you need to edit files without rebuilding the WAR every time;
- your workflow uses FTP or file manager uploads directly to the application directory;
- you are testing changes frequently in a development or staging environment;
- the hosting service exposes an application root folder for direct file placement.
Important points:
- the folder name becomes the context path unless ROOT is used;
- the directory must contain the correct Java web app structure;
- Tomcat must have permission to read the files;
- some changes may require a restart or redeploy to take effect.
Deploying to the root path
If you want your application to open directly on the domain without an extra folder in the URL, you need to deploy it to the root context. In Tomcat, this is usually done with a file named ROOT.war or a directory named ROOT, depending on the deployment method supported by the hosting platform.
This is useful for:
- single-application websites;
- landing pages built on JSP or servlets;
- apps that should load at
https://yourdomain.example/rather than/appname.
Before using the root path, make sure there is no existing website content in the same location that could conflict with the Tomcat application. On a managed hosting service, the root deployment may be controlled by the Plesk extension and not by direct file placement alone.
Where to upload files: FTP, File Manager, or Plesk
The right deploy path is only useful if you upload to it through the correct method. On a hosting platform, you may use FTP, SFTP, File Manager, or the application management tools in Plesk. The best choice depends on the size of the application and the deployment workflow.
Use FTP or SFTP for larger application packages
FTP or SFTP is practical when you need to upload a WAR file or a full application directory. Make sure you connect to the account that owns the Tomcat service and place the files in the exact deployment folder.
Use the Plesk File Manager for quick changes
File Manager is suitable for small updates, such as replacing a JSP file, adjusting a configuration file, or verifying the current folder structure. It is also helpful when you want to confirm the application path without leaving the control panel.
Use the My App Server interface for controlled deployment
When your hosting plan includes a custom Java extension, the platform may offer direct controls for deploying, starting, stopping, or restarting the application server. In that case, the safest deploy path is the one selected inside the service settings. This is often better than manually guessing the file path from the filesystem.
Common Tomcat deploy path examples
Although every hosting setup may differ, the following examples show the type of deploy path you may encounter:
/opt/tomcat/webapps//var/lib/tomcat/webapps//home/username/appserver/webapps//home/username/plesk/my-app-server/tomcat/webapps//home/username/private-jvm/webapps/
These are examples only. Your actual path may be different because managed hosting often uses account-specific directories and isolated services.
How to verify you used the correct deploy path
After uploading the application, check these points to confirm that the path is correct:
- the WAR or app folder is present in the Tomcat deploy directory;
- the file name matches the desired context path;
- the application appears in the Plesk service list if applicable;
- Tomcat logs show that the app was deployed successfully;
- the application URL returns the expected home page or status endpoint.
If the application does not load, the issue may be related to path, permissions, Java version, or a deployment error inside the app itself.
Typical mistakes when choosing a deploy path
Many deployment problems are caused by placing the app in the wrong folder. The most common mistakes are:
- uploading the WAR into the website document root instead of the Tomcat webapps directory;
- using the wrong domain’s folder in a multi-domain account;
- placing files outside the Tomcat instance managed by My App Server;
- forgetting that the app name changes the URL path;
- mixing up root deployment and subpath deployment;
- changing files without restarting the service when restart is required.
To avoid these problems, always confirm the application server name, Tomcat version, and deployment root before copying files.
Best practice for Java hosting and Tomcat deployment
For Java hosting in a shared or managed environment, the best practice is to deploy one application per service instance and keep the package structure simple. Tomcat hosting works best when the deploy path is clear, permissions are correct, and the app is matched to the right Java version.
Recommended workflow:
- Select the correct Tomcat version in Plesk.
- Confirm the active Java version and service path.
- Package the application as WAR if possible.
- Upload it to the service-specific deploy directory.
- Restart or redeploy only if the platform requires it.
- Review logs if the application does not start.
This approach is especially useful for JSP hosting, servlet hosting, and small to medium Java web applications that need a private JVM and straightforward control from the hosting panel.
Troubleshooting when the application does not deploy
If your Tomcat application does not start after upload, use this checklist:
- Confirm the file is a valid WAR or the folder structure is complete.
- Check that the file name does not contain unsupported characters.
- Verify that you uploaded to the correct Tomcat deploy path.
- Make sure the selected Java version matches the app requirements.
- Review application and Tomcat logs for startup errors.
- Check whether the service needs a manual restart.
- Ensure file permissions allow Tomcat to read the deployment files.
If the app works locally but fails on the hosting platform, the issue is often related to Java compatibility, missing dependencies, or a configuration difference rather than the deploy path itself.
FAQ
What deploy path should I use for a Tomcat application on managed hosting?
Use the Tomcat webapps directory assigned to your service, or the exact path shown in Plesk or the My App Server settings. Do not assume a generic server path is correct for your account.
Should I upload a WAR file or an extracted folder?
WAR is usually the simplest and safest option. Use an extracted folder only if your workflow requires direct file editing or the platform specifically supports exploded deployments.
Can I deploy my app to the domain root?
Yes, if your hosting setup allows root deployment. This is usually done with ROOT.war or a ROOT application directory. Check your service configuration first.
Why is my application deployed under a different URL path?
Tomcat often uses the file or folder name as the context path. For example, myapp.war usually becomes /myapp. Rename the package or configure the root context if you need a different URL.
Do I need to restart Tomcat after uploading files?
Sometimes yes, sometimes no. If auto-deploy is enabled, Tomcat may deploy automatically. In managed hosting, a restart may still be required depending on the platform settings.
Can I use FTP to deploy to Tomcat?
Yes, if FTP or SFTP access is available. Just make sure you upload to the correct Tomcat deployment folder, not the generic website directory.
What if my app uses a custom Java version?
Select the matching Java version in the service settings before deploying. A wrong Java version can prevent Tomcat from starting the application even if the path is correct.
Conclusion
The correct deploy path for a Tomcat application is the folder that belongs to your active Tomcat service, usually the webapps directory or the application root defined in Plesk. In a managed hosting setup with My App Server, the safest approach is to use the path shown in the control panel, because it reflects the actual private JVM and Tomcat instance assigned to your account.
For WAR deployments, upload the package to the service-specific deploy directory. For exploded applications, use the corresponding application root. If you want the app at the domain root, use ROOT deployment where supported. Always verify the Java version, context path, and service status after upload to make sure the application starts correctly.