When you host a Tomcat application on a managed hosting account, the public URL is usually determined by the domain, the selected context path, and the way the application is deployed in Tomcat. If the app opens at the wrong address, the fix is often simple: check the context root, the WAR filename, the webapp folder name, and any Apache or Plesk routing rules that may sit in front of Tomcat.
In an ITA Java hosting environment with My App Server, you can run your own Apache Tomcat instance and private JVM inside a shared hosting account. That gives you control over the application server, but the public URL still needs to be mapped correctly so visitors reach the app at the exact path you want, such as https://example.co.uk/, https://example.co.uk/app/, or a subdomain like https://app.example.co.uk/.
How Tomcat decides the public URL
Tomcat maps each web application to a context path. This context path becomes part of the public URL. For example:
- ROOT application maps to the domain root: https://example.co.uk/
- app maps to: https://example.co.uk/app/
- shop maps to: https://example.co.uk/shop/
In a hosting control panel environment, especially with Plesk, the visible URL may also be influenced by:
- the domain or subdomain assigned to the service
- Apache virtual host routing
- reverse proxy or rewrite rules
- the selected Tomcat application directory
- the name of the deployed WAR file
If these elements do not match, the app may open under an unexpected path or return a 404 error.
Common Tomcat URL patterns
1. Mapping the app to the domain root
If you want the application to open at the main domain without any extra path, it must be deployed as the ROOT application.
Typical URL:
- https://example.co.uk/
This is useful for:
- main websites built on JSP or Servlets
- single-app hosting setups
- landing pages or custom application portals
In Tomcat, this usually means using a ROOT.war file or a ROOT application directory.
2. Mapping the app to a subpath
If you want the app to run under a specific path, deploy it with that name.
Typical URLs:
- https://example.co.uk/app/
- https://example.co.uk/customer/
- https://example.co.uk/admin/
This is a common setup when one domain hosts multiple Java applications or when the Tomcat service sits behind Apache and serves only one part of the website.
3. Mapping the app to a subdomain
You can also point a subdomain to the Java application and keep the app path clean.
Typical URLs:
- https://app.example.co.uk/
- https://api.example.co.uk/
- https://portal.example.co.uk/
This is often the cleanest option when the application should be separated from the main website. In managed hosting, you usually create the subdomain in Plesk and then connect the Tomcat app to that host name.
How to map a Tomcat app to the correct public URL
Use the steps below to make sure the application opens at the right address.
Step 1: Decide the target URL first
Before you deploy, decide whether the app should open at:
- the domain root
- a subpath under the domain
- a separate subdomain
This decision affects the Tomcat context path, deployment folder, and any Apache routing in front of the application.
Step 2: Check the Tomcat context path
Tomcat usually uses the application name as the context path. For example:
- myapp.war becomes /myapp
- shop.war becomes /shop
- ROOT.war becomes /
If the app is deployed from a folder, the folder name may also define the context path. If you want a different public URL, rename the WAR file or redeploy under the correct context name.
Step 3: Verify the deployment folder name
In Tomcat, the deployment folder name matters. If the folder is called app, the public path is usually /app. If you upload the application as ROOT, it is intended for the main domain.
Check for these common mistakes:
- the app folder name does not match the intended URL
- both ROOT and another app are deployed, causing confusion
- an old deployment is still present and Tomcat is serving it instead of the new build
Step 4: Review Apache and Plesk routing
In a managed hosting setup, Apache may sit in front of Tomcat. If so, Apache can forward requests to the Java application. In Plesk environments, the domain configuration can also determine whether the app is served directly or through a proxy setup.
Look for:
- rewrite rules that redirect requests to another path
- proxy settings pointing to the wrong backend
- domain document root conflicts
- old .htaccess rules affecting the URL
If the app should open at the root domain but Apache is still serving a static site or another application, the Tomcat app may not be reached even if it is deployed correctly.
Step 5: Make sure the application context is not hardcoded
Some Java applications generate absolute links using a fixed base URL. That can make it look like the app is mapped incorrectly, even when Tomcat is configured properly.
Check whether the application has:
- hardcoded links to localhost
- an old domain name inside config files
- fixed absolute paths instead of relative paths
- environment variables that still point to the staging URL
For hosted Tomcat applications, it is usually better to keep the app flexible and read the base URL from the request or configuration.
Best practice: use ROOT for the main site and separate context paths for add-ons
If the Java application is the primary website, deploy it as ROOT. If it is an extra module, keep it under its own path.
Example structure:
- https://example.co.uk/ → main public site
- https://example.co.uk/app/ → application portal
- https://example.co.uk/admin/ → admin area
This structure is easy to maintain in a hosting control panel and avoids URL conflicts when you update releases.
How this works in My App Server with Plesk
ITA’s My App Server gives you practical control over Java hosting through Plesk. You can install and manage a private Apache Tomcat instance and a private JVM inside your hosting account. That is useful when you need JSP hosting, servlet hosting, or a small-to-medium Java application without moving to a complex enterprise platform.
From a URL mapping point of view, the key benefits are:
- you can choose the Java version that matches your app
- you can deploy WAR files or custom webapp folders
- you can control the service from the panel
- you can align the application path with the domain or subdomain
Because the Tomcat instance is private to your hosting account, URL mapping is typically easier to manage than on a shared generic server. Still, the public URL must match the deployment name and the host configuration.
Practical examples
Example 1: Main site on the root domain
You upload ROOT.war to the Tomcat deployment location. After deployment, the app should open at:
- https://example.co.uk/
If it opens at /ROOT or /ROOT.war, the deployment name is not being interpreted correctly, or an older deployment remains active.
Example 2: App under /portal
You upload portal.war. The app should open at:
- https://example.co.uk/portal/
If you want a different path, rename the file or set the context explicitly in the Tomcat configuration supported by your hosting environment.
Example 3: App on a subdomain
You create app.example.co.uk in Plesk and connect it to the Tomcat application. The app should open at:
- https://app.example.co.uk/
This is a good choice if the application needs its own public address and should not share the main website path.
Troubleshooting when the app opens at the wrong URL
The app shows 404 at the expected path
Possible causes:
- wrong context path
- WAR file name does not match the target URL
- Tomcat deployment is incomplete
- Apache is routing the request elsewhere
Fix:
- confirm the deployed name
- check Tomcat service status
- remove old builds and redeploy cleanly
- verify Plesk domain and proxy settings
The app opens one level deeper than expected
If the app is available at /app but not at the root domain, it is usually because it was deployed as app.war instead of ROOT.war.
Fix:
- rename the WAR to ROOT.war
- redeploy to the correct location
- clear old cached deployments if needed
The browser redirects to localhost or an old domain
This is usually an application-level configuration problem, not a Tomcat routing problem.
Fix:
- inspect config files, properties and environment variables
- replace hardcoded base URLs
- use request-based URL building where possible
The old version still appears after deployment
Possible causes:
- Tomcat cached the previous deployment
- the old app folder was not removed
- the service was not restarted after upload
- Apache cache or browser cache is serving outdated content
Fix:
- remove the old build completely
- reinstall or restart the Java service if your control panel allows it
- test in a private window or another browser
Recommended deployment checklist
- Choose the final public URL before uploading.
- Match the WAR name to the desired context path.
- Use ROOT only if the app should open at the domain root.
- Check Apache and Plesk routing for conflicts.
- Remove old deployments before uploading a new version.
- Verify that the app does not contain hardcoded base URLs.
- Test the final URL in a browser after deployment.
Tips for cleaner Tomcat URL management
Use simple, predictable names
Short deployment names make it easier to understand and maintain the public path. For example, portal is clearer than portal-v2-final.
Keep the main app at the root only when needed
If multiple apps share one host name, avoid unnecessary ROOT deployments. Use separate paths or subdomains to keep the structure clear.
Document the mapping
For each release, note the relationship between:
- WAR file name
- Tomcat context path
- domain or subdomain
- deployment date
This helps when you update builds through the control panel and need to confirm the live URL quickly.
Check Java version compatibility
In managed Java hosting, the wrong Java version can stop the app from starting. If Tomcat is mapped correctly but the app still fails, confirm that the selected Java version matches the application requirements.
FAQ
How do I make a Tomcat app open at the main domain?
Deploy it as ROOT.war or use the root context in your Tomcat setup. Then verify that Apache or Plesk is forwarding the domain to that application.
Why does my Tomcat app open at /app instead of /?
Because the application is deployed with the name app. Tomcat uses the application name as the context path unless the app is deployed as ROOT.
Can I map one Tomcat instance to a subdomain?
Yes. In a hosting control panel such as Plesk, you can create a subdomain and connect it to the Java application so it opens at a clean URL like app.example.co.uk.
Does Apache affect the public URL of a Tomcat app?
Yes. If Apache is acting as a front-end or reverse proxy, its rules can change which URL reaches Tomcat. Incorrect rewrite or proxy settings may send traffic to the wrong path.
What should I check if the old version still appears?
Check for old deployment folders, cached files, service restart needs, and browser cache. Also make sure you uploaded the new WAR to the correct context name.
Is this suitable for JSP and Servlet applications?
Yes. This setup is well suited for JSP hosting, servlet hosting, and small-to-medium Java applications that need a private Tomcat and Java runtime.
Conclusion
Mapping a Tomcat app to the right public URL is mostly about keeping three things aligned: the domain or subdomain, the Tomcat context path, and the web server routing in front of it. In a managed hosting setup with My App Server and Plesk, this gives you a practical and flexible way to host Java applications without unnecessary complexity.
If the application should open at the root domain, deploy it as ROOT. If it should open under a path, match the WAR or folder name to that path. If it should live on a separate subdomain, connect that host name to the app and verify that Apache and Tomcat are pointing to the same place. Once those pieces are correct, the public URL becomes predictable and easier to maintain during future releases.