If you are deploying a JSP application in a UK hosting account, the correct deploy path depends on how the application is being served: as a standard web root application, as a Tomcat application, or through a managed Java environment in Plesk. In most cases, JSP files should not be placed directly in the public document root unless your hosting setup is specifically configured to interpret them there. On a Java hosting platform with a private Tomcat instance, the safest and most common deploy path is the web application directory used by Tomcat, usually under the application’s root folder inside the service space provided by your control panel.
For shared hosting plans with Java support, especially those using a Plesk extension such as My App Server, the practical answer is simple: deploy your JSP application to the Tomcat application path assigned to your service, then let Tomcat handle compilation and servlet processing. This gives you cleaner application management, better control over the Java version, and a more reliable setup than placing JSP files in a generic FTP folder and expecting Apache to serve them directly.
Which deploy path is correct for a JSP application?
The correct deploy path is the path where your Java application server expects the web app content to live. For JSP hosting, that is typically the Tomcat web application directory, not the ordinary website document root used for static HTML or PHP sites.
In a typical Tomcat-based setup, your deployment will follow one of these patterns:
- WAR upload path – upload a WAR package to the application deployment directory and let Tomcat unpack it.
- Exploded application path – upload the application folders and files directly into the assigned app directory.
- Custom app server path – use the specific directory created by your hosting control panel or My App Server service for that domain or subdomain.
For managed hosting customers, the control panel usually defines this for you. If you are using Plesk with a Java extension, the deploy path is commonly tied to the service instance rather than a generic FTP folder. That matters because JSP pages need a Java servlet container such as Apache Tomcat to compile and run.
Why JSP files should not usually go in the public web root
JSP is not a static file format. A .jsp file must be processed by a Java application server before it can return HTML to the browser. If you upload JSP files to a normal web root on a hosting account that does not route requests through Tomcat, the files will either download as plain text, show as source, or fail with a server error.
That is why the deploy path for JSP hosting is usually separate from the standard FTP path used for images, CSS, or static HTML.
Typical reasons to avoid the public web root for JSP deployment include:
- the web server may not be configured to compile JSP files;
- Java classes and libraries need a proper application structure;
- Tomcat expects a defined web application layout;
- control panel services may manage start, stop, and restart actions at the application level;
- separating static and Java content makes troubleshooting easier.
Recommended deploy paths in a Plesk Java hosting setup
If your hosting account uses Plesk and a Java hosting extension such as My App Server, the recommended deploy path is the application’s dedicated folder created for that service. The exact folder name can vary, but the structure generally follows the Tomcat model.
1. Tomcat web application directory
This is the main location for JSP and servlet applications. You deploy your application package here so Tomcat can run it as a web app.
Use this option when:
- you are deploying a WAR file;
- your app contains JSP, servlets, and Java libraries;
- you want Tomcat to manage compilation and runtime processing;
- you need a clean app-specific directory structure.
2. Application root for an exploded deployment
An exploded deployment means the application is uploaded as folders and files rather than a single WAR archive. This is useful when you want to edit files more directly, test updates in parts, or manage a smaller JSP application manually.
Use this option when:
- you are updating JSP pages frequently;
- you need direct access to the application structure;
- the hosting platform supports file-level deployments in the service folder;
- your application does not require repeated packaging into WAR files.
3. Custom app server path assigned in Plesk
Some managed hosting setups allow a custom application server instance. In that case, the path is the one assigned by the platform to that service. This is especially useful when you want a private JVM or an isolated Tomcat instance within your hosting account.
Use this option when:
- you have installed a Tomcat version through the control panel;
- you are running a private JVM under your hosting account;
- your app server has a separate service control area;
- you want consistent deployment behavior across updates.
How to find the deploy path in your hosting control panel
If you are not sure where your JSP application should be uploaded, check the application server settings in Plesk. In a Java hosting service, the path is usually shown in the My App Server or Java application section.
Look for items such as:
- document root or application root;
- deployment directory;
- Tomcat base path;
- WAR upload location;
- service path for the selected domain or subdomain;
- application context path.
If you are using an FTP client, the folder you see after connecting may not be the same as the actual web app runtime location. The FTP folder is for file transfer, but the runtime path is the one the Java service uses. In managed hosting, these are often linked but not always identical.
Practical check before upload
- Confirm that Java hosting is enabled for the domain or subdomain.
- Check whether Tomcat has already been installed from the control panel.
- Verify which Java version is selected for the app server.
- Confirm whether you should upload a WAR or an exploded folder structure.
- Restart or redeploy the service after uploading files if required.
Typical JSP application folder structure
When deploying a JSP application, your files should usually follow a standard Java web application structure. This helps Tomcat recognize the application correctly and load JSP pages, classes, and libraries.
A common structure looks like this:
WEB-INF/for configuration and protected resources;WEB-INF/web.xmlfor deployment descriptors, if used;WEB-INF/classes/for compiled classes;WEB-INF/lib/for JAR dependencies;- JSP files placed in the web root or in subfolders as required by the application;
- static assets such as
css,js, and images alongside the JSP pages.
Keeping this structure intact is important. If you place files in the wrong folder, Tomcat may not load your application correctly, or JSP compilation may fail.
WAR deployment versus direct file deployment
In a Tomcat hosting environment, there are two common ways to deploy a JSP app: as a WAR archive or as an exploded directory. The right choice depends on how often you update the app and how the hosting platform is configured.
WAR deployment
A WAR file is the simplest deploy format when you want a complete package. You upload one archive and Tomcat handles the rest.
Advantages:
- easy to upload over FTP or through the control panel;
- keeps the application packaged and consistent;
- reduces the chance of missing files during transfer;
- useful for stable releases.
Best for:
- production-ready app versions;
- small and medium JSP applications;
- teams that build locally and deploy in one file.
Exploded deployment
An exploded deployment means you upload the full application directory tree. This is more flexible for incremental changes, but it requires careful file management.
Advantages:
- easy to edit individual JSP files;
- faster small updates without repackaging;
- good for testing and maintenance;
- useful when you manage files directly in Plesk or over FTP.
Best for:
- development and staged updates;
- applications with frequent page changes;
- users who prefer direct file access.
Step-by-step: where to upload a JSP application
If you are deploying a JSP app on a managed hosting platform with Plesk and My App Server, follow this process:
- Open Plesk and go to the Java application or My App Server section.
- Select the domain or subdomain that will run the application.
- Check which Tomcat or Java version is active.
- Find the application root, deployment directory, or WAR upload field.
- Upload your WAR file or application folder to that location.
- Confirm that the folder structure includes
WEB-INFand any required libraries. - Redeploy or restart the service if the platform requires it.
- Test the URL to make sure JSP pages compile and render correctly.
If the application does not start, review the logs and confirm that the deploy path matches the service’s expected location. Most JSP deployment problems come from an incorrect directory structure, a missing JAR, or a mismatch between the deployed files and the app server path.
How deploy paths relate to Tomcat context paths
In Tomcat, the deploy path on disk is not the same as the URL path seen by visitors. The file system location is where the application lives on the server, while the context path is the web address used to reach it.
For example:
- the deploy path may be a directory assigned in your hosting account;
- the context path may be
/appnameor the root domain; - the application may be accessed through the domain or subdomain linked to the service.
This distinction matters because changing the folder on disk does not always change the URL, and changing the URL route does not always move the files. In Plesk-based Java hosting, the platform often keeps both aligned for easier management.
Common mistakes when choosing a deploy path
Many JSP deployment issues come from uploading to the wrong place. These are the most common mistakes to avoid:
- placing JSP files in the HTML-only document root;
- uploading a WAR file but not redeploying the Java service;
- removing the
WEB-INFfolder or changing its structure; - mixing static website files with application runtime files;
- using the wrong Java version for the app;
- uploading libraries to the wrong directory instead of
WEB-INF/lib; - expecting Apache alone to run JSP without Tomcat.
If your hosting plan includes a private JVM and managed Tomcat through My App Server, the safest practice is to follow the deployment path shown in the control panel and avoid manual folder guessing.
Troubleshooting if the JSP app does not work after upload
If your JSP application is uploaded but does not run, check the following:
- Wrong deploy path – confirm the files are in the Tomcat app directory, not just an FTP folder.
- Incorrect structure – verify that
WEB-INFand required files are present. - Java version mismatch – confirm the app server uses a compatible Java release.
- Service not restarted – some changes require a redeploy or restart from Plesk.
- Missing dependencies – check that all JAR files are uploaded to
WEB-INF/lib. - Permission issues – file ownership or permissions may block access.
- Context path conflict – another app may already use the same URL route.
When in doubt, review the service logs through the control panel. Logs usually show whether Tomcat found the app, whether compilation failed, or whether the path was invalid.
Best practice for UK JSP hosting customers
For UK customers using JSP hosting, the best practice is to keep your application inside the Tomcat-managed deploy path provided by the hosting platform. This gives you a cleaner setup and avoids problems caused by putting Java files in a normal website folder.
Recommended approach:
- use the Java hosting or My App Server area in Plesk;
- deploy to the Tomcat application directory shown there;
- choose WAR deployment for stable releases;
- use exploded deployment only when you need direct file-level updates;
- keep static assets organized separately within the app structure;
- check service control options after every major update.
This approach works well for JSP hosting, servlet hosting, small Java web apps, and private JVM use cases where you need practical control without the complexity of enterprise application server management.
FAQ
Should I upload JSP files to public_html?
Usually no. JSP files should be deployed to the Tomcat application path, not a standard static website folder, unless your hosting setup explicitly routes that folder through the Java service.
Can I run JSP from ordinary FTP space?
FTP is only the transfer method. The files must still be placed in the deploy path used by Tomcat or the managed Java service. Uploading by FTP does not make a folder JSP-ready by itself.
What is the safest deploy method for a JSP application?
For most users, the safest method is uploading a WAR file to the Tomcat deployment path shown in Plesk. This reduces file structure errors and makes redeployment easier.
Do I need Apache Tomcat for JSP hosting?
Yes. JSP pages need a servlet container such as Apache Tomcat to compile and run. Apache alone is not enough for JSP processing.
Can I use a custom Java version for the application?
In a managed Java hosting setup, often yes. Many control panels allow you to select a Java version for the application server, which is useful for compatibility with different JSP applications.
What if my app uses classes and JAR files?
Place compiled classes in WEB-INF/classes and libraries in WEB-INF/lib unless your application’s structure requires something different. Keeping these in the correct path is essential for Tomcat to load them.
Is this setup suitable for large enterprise clusters?
This kind of hosting is designed for practical JSP, servlet, and Tomcat deployments on shared or managed services, not for heavy enterprise cluster architectures or complex high-availability designs.
Summary
The correct deploy path for a JSP application in the UK depends on the Java hosting setup, but in most cases it is the Tomcat-managed application directory provided by your control panel, not the generic web root. If you are using a managed Plesk environment with My App Server, deploy your WAR file or exploded application to the app server path assigned to your domain or subdomain. That is the most reliable way to run JSP pages, servlets, and small to medium Java web apps with proper control over the runtime.
If you are unsure which path to use, check the Java hosting settings in Plesk, verify the active Tomcat instance, and follow the deployment directory shown there. Choosing the correct path from the start will save time, prevent runtime errors, and make future updates much easier.