For most Tomcat deployments in Plesk-based hosting, the correct deploy path is the application’s web root inside the Tomcat instance managed by your hosting panel, not the public website document root. If you are using a hosted Java setup such as My App Server, your deployment target is usually the Tomcat app directory or the WAR upload location provided by the service, where the container can unpack and run your application with the correct Java version and service settings.
Choosing the right path matters because Tomcat does not serve Java applications from the same place as static HTML files. A JSP, servlet, or WAR package needs to be deployed where the Tomcat service expects it, so the application can start correctly, load its libraries, and bind to the configured context.
What “deploy path” means for a Tomcat application
The deploy path is the file system location where you place your application package or exploded application directory so Tomcat can load it. In a managed hosting environment, this is usually controlled through Plesk or a custom Java hosting extension rather than through a raw server shell workflow.
In practice, the deploy path may be one of the following:
- a WAR upload directory used by the control panel
- an applications folder under the Tomcat instance
- an expanded webapp directory such as a context folder
- a custom application path configured in the panel
The important point is that Tomcat must be able to read the files from that location, unpack them if needed, and map the application to a context path such as /myapp.
Recommended deploy path in Plesk-based Tomcat hosting
If your hosting account uses My App Server or a similar Plesk extension for Java hosting, the recommended deploy path is the one assigned by the service for the specific Tomcat instance. In many setups, this is a path inside the subscription’s private application area rather than the site’s default httpdocs folder.
As a general rule:
- Static website files go to the website document root.
- Tomcat applications go to the Tomcat deployment area.
- WAR files should be uploaded to the application deploy location defined by the control panel.
If you place a Java application in the wrong directory, the web server may show a plain directory listing, a download prompt, or a 404 error instead of running the application.
How Tomcat deploy paths work with WAR files
WAR is the most common packaging format for Tomcat applications. When you upload a WAR file to the correct deploy path, Tomcat can unpack it into a web application directory and start the app automatically, depending on your panel settings.
Typical WAR deployment flow
- Build your application as a WAR file.
- Upload the WAR to the Tomcat deployment location in Plesk.
- Let Tomcat unpack it or trigger deployment from the panel.
- Check logs and service status if the app does not start.
- Access the app using its mapped context path.
In managed hosting, this approach is usually simpler than manual server-side deployment because the panel handles service control, Java version selection, and path mapping more safely.
Difference between document root and Tomcat deploy path
This is one of the most common points of confusion.
The document root is where Apache or the website filesystem serves static content such as HTML, images, CSS, and JavaScript. The Tomcat deploy path is where the Java application lives so the Tomcat servlet container can execute JSPs and servlets.
Use this simple distinction:
- Document root = files served directly by the web server
- Tomcat deploy path = files processed by the Java application server
If your site uses Apache in front of Tomcat, Apache may proxy requests to Tomcat or serve a front-end layer while Tomcat handles the Java application. In that case, the deploy path still belongs to Tomcat, not the Apache document root.
Where to place different types of Java application files
Not every Java deployment looks the same. The correct location can depend on the application format.
WAR packages
Upload the WAR file to the panel-defined Tomcat deployment location. This is the simplest and most reliable method for most hosted Tomcat applications.
Exploded application directories
If you deploy an expanded application folder instead of a WAR, place the directory in the Tomcat webapps area or in the folder specified by the hosting platform. Make sure the folder structure contains the expected WEB-INF directory and application resources.
JSP-only sites
JSP pages still need to be located inside a Tomcat-managed web application directory. They should not be uploaded as plain files to the website root unless that root is actually mapped to Tomcat by the service.
Servlet applications
Servlet-based applications should be deployed as a complete web application, typically in WAR form, so Tomcat can load the classes, descriptors, and libraries correctly.
How to find the correct deploy path in My App Server
In a hosting environment with a custom Java extension, the deploy path is usually visible in the service panel or in the app server settings. You should not guess the path by uploading files at random and testing them one by one.
Look for information such as:
- the current application root
- the active Tomcat instance path
- the context name or URL mapping
- the upload or deploy directory for WAR files
- the service user or subscription path
If the platform provides multiple Java or Tomcat versions, the deploy path may stay the same while the runtime changes. In that case, the Java version is selected in the panel, and the application files remain in the service’s application directory.
Practical steps to deploy a Tomcat application
Use the following workflow for a clean deployment in Plesk or My App Server.
1. Confirm the application format
Check whether you are deploying a WAR, an exploded directory, or a custom Java application package. This determines where and how you should upload the files.
2. Check the service settings
Open the hosting control panel and verify:
- the selected Java version
- the active Tomcat service
- the application context path
- the deploy or webapps directory
3. Upload to the correct location
Place the files in the Tomcat deployment path provided by the panel. Do not use the website document root unless the hosting setup explicitly maps it to Tomcat.
4. Keep the package structure intact
If you upload an exploded app, preserve the required folder structure. Missing configuration files or incorrect nesting can stop the application from starting.
5. Restart or redeploy if needed
Some changes take effect automatically, while others require a service restart or redeploy action from the control panel. Use the panel controls rather than direct system tools whenever possible in managed hosting.
6. Test the application URL
Open the context path assigned to the application and check whether the app loads correctly. If it does not, inspect the Tomcat logs for deployment errors.
Common mistakes when choosing a Tomcat deploy path
Many deployment problems come from using the wrong folder. These are the most common mistakes to avoid.
- Uploading WAR files to the website root instead of the Tomcat deployment folder
- Mixing static and Java content in the same directory without checking the service mapping
- Using the wrong context path after deployment
- Forgetting to restart or redeploy after updating application files
- Uploading incomplete application folders with missing
WEB-INFor libraries - Assuming Apache document root and Tomcat app root are the same
If the app does not appear after upload, the first thing to verify is whether it was placed in the correct deploy path for the Tomcat service.
Deploy path examples for hosted Tomcat environments
Exact paths vary between hosting platforms, but the logic is similar. Here are examples of what the deploy target might look like in a managed environment:
- a private
webappsdirectory under the Tomcat instance - a subscription-specific Java application folder
- a path selected through the Plesk extension for the active service
- a WAR upload area that the panel monitors for new deployments
If your platform supports multiple applications, each app may have its own deployment path or context configuration. That helps keep apps separate within the same hosting account.
How Apache and Tomcat affect the deploy path
In many hosting setups, Apache is used as the front-end web server and Tomcat runs behind it. This does not change where the Java app itself is deployed. Tomcat still needs its own application path; Apache simply routes or proxies traffic.
Use Apache document root for:
- static assets
- landing pages
- reverse proxy configuration when provided by the host
Use the Tomcat deploy path for:
- WAR files
- JSP pages
- Servlets
- Java libraries and web application resources
This separation is especially important in shared hosting, where the hosting platform manages service boundaries and file permissions for you.
Permissions and file access considerations
Even when the deploy path is correct, deployment can still fail if file permissions are wrong. Tomcat must be able to read the package and, in some cases, write temporary files during unpacking or runtime.
Check that:
- the application files are readable by the service user
- the deploy directory allows uploads through the panel or FTP
- temporary and work directories are available if the app needs them
- ownership is consistent after manual uploads
In managed hosting, it is best to use the file permissions recommended by the control panel rather than changing them manually unless support instructs you otherwise.
How to troubleshoot a wrong deploy path
If the application is not loading, use this checklist.
- Confirm that the files were uploaded to the Tomcat deploy directory.
- Verify that the WAR or app folder name matches the expected context.
- Check whether the correct Java version is enabled.
- Review Tomcat logs for deployment errors.
- Confirm that the service is running.
- Ensure the app was not uploaded to the Apache document root by mistake.
Typical symptoms of a wrong deploy path include:
- 404 Not Found
- default Apache page instead of the app
- download of the WAR file instead of execution
- empty page or startup failure
- context path not matching the URL you expected
Best practice for Tomcat deployment in managed hosting
The safest deployment workflow is to use the hosting control panel as the source of truth. Let the panel define the path, the Java runtime, and the service lifecycle. That reduces the chance of mismatched paths, wrong ownership, or manual misconfiguration.
For small and medium Java applications, this approach gives you practical control without needing to manage a full standalone server stack. You can deploy WAR files, manage a private JVM, switch Java versions when needed, and keep the application isolated within the hosting account.
FAQ
Should I upload my Tomcat app to httpdocs?
Only if your hosting setup explicitly maps the website root to Tomcat. In most managed Java hosting setups, the correct deploy path is separate from httpdocs.
Can I deploy a WAR file through FTP?
Yes, if the hosting platform allows it and the file is uploaded to the correct Tomcat deployment directory. Some panels also provide a dedicated upload or deploy action.
What if my JSP files do not run?
Usually the files are in the wrong directory, outside the Tomcat web application path, or the app was not deployed as a proper Tomcat webapp.
Do I need a custom context path?
Not always. Many applications work with the default context name derived from the WAR file name. Use a custom context only if your application or hosting configuration requires it.
Is the deploy path the same for all Java versions?
Usually the application path stays the same, while the runtime Java version changes separately in the control panel. Always confirm this in your hosting interface.
What should I check first if deployment fails?
Start with the upload location, the service status, and the Tomcat logs. In most cases, a wrong path or missing application structure is the cause.
Conclusion
For a Tomcat application in UK-focused managed hosting, the correct deploy path is the Tomcat application directory defined by your control panel, not the standard website document root. If you are using a service such as My App Server, deploy the WAR or application files in the path assigned by the panel, then use the service controls to manage Java, Tomcat, and redeployment.
When you keep the deploy path aligned with the Tomcat service, deployment becomes much more predictable: the application starts correctly, JSPs and servlets run as expected, and troubleshooting becomes far easier.