When you deploy a Tomcat application, the public URL is usually defined by the application’s context path. In practice, that means the URL users type in their browser must match the way the app is deployed in Tomcat, or the way the web server forwards traffic to it. If the mapping is wrong, the application may still run, but it will open at an unexpected address, return 404 errors, or conflict with another site on the same hosting account.
On a managed hosting platform with Plesk and a Java hosting extension such as My App Server, you can control this behaviour without handling the full server stack manually. This is especially useful for shared hosting accounts with a private JVM or a dedicated Tomcat instance inside the account, where you want a clean public URL for a WAR, JSP or servlet application.
What Tomcat uses to decide the public URL
In Tomcat, the public address of an application is based on its context root. The context root is the path portion after the domain name. For example, if your app is available at https://example.com/shop, then /shop is the context path.
Tomcat can determine this mapping in several ways:
- WAR file name — a file named shop.war usually deploys as /shop.
- Context configuration — a context file can explicitly define the path.
- Root deployment — an application can be mapped to the site root, such as https://example.com/.
- Reverse proxy or Apache routing — Apache can forward a public URL to the Tomcat backend.
In hosted environments, the most common approach is a simple mapping between the deployed application and the URL path. For example, if the app should be available as /myapp, the deployment name, context root, and proxy rules should all point to that same path.
Common ways to map a Tomcat app to a public URL
1. Deploy the WAR with the required name
This is the simplest method. If you want the app to appear at /store, upload the WAR as store.war. Tomcat usually uses the file name as the context path.
Examples:
- app.war → /app
- portal.war → /portal
- ROOT.war → / (site root)
This approach is good when you want a quick deployment and do not need a custom context definition.
2. Define the context path in a Tomcat context file
If your hosting setup allows custom Tomcat configuration, a context file can explicitly set the URL path. This is useful when the WAR name does not match the desired public URL or when you want to keep deployment naming separate from URL naming.
A context file typically defines:
- the application path
- the web application directory or WAR location
- optional reload or resource settings
This is the preferred method when you need predictable URL behaviour in a managed hosting environment and want to avoid renaming files for every release.
3. Use Apache as a front end and route to Tomcat
In a Plesk-based hosting environment, Apache often serves the domain and forwards only selected requests to Tomcat or the private JVM. This is helpful when the public site has both static content and a Java application, or when you want one domain to serve a Java app under a specific path.
For example:
- https://example.com/ serves the main site through Apache
- https://example.com/app forwards to the Tomcat application
This setup is common when a Java application is one part of a broader hosting account and should share the same domain with other content.
How to choose the right mapping
The best mapping depends on how you want users to access the application and how your deployment process works. Use the following rule of thumb:
- Choose WAR file naming for simple deployments and fast updates.
- Choose a context file if you need a stable path independent of the file name.
- Choose Apache routing if the public URL must be integrated with other site content or another application already served on the same domain.
For a managed Tomcat hosting account, the simplest and most maintainable setup is usually to keep the WAR name, context root, and public URL aligned.
Step-by-step: map a Tomcat app to the correct URL
Step 1: Decide the target public path
Start by deciding where the app should live:
- Root domain: https://domain.com/
- Subpath: https://domain.com/app
- Separate subdomain: https://app.domain.com/
For hosted Java apps, a subpath is often easiest if the site already has content on the main domain. A subdomain is cleaner when the application should behave like a separate service.
Step 2: Check how the app is packaged
Look at the file name and structure of the deployment package:
- If it is a WAR file, the name may define the context root.
- If the app is unpacked in a folder, the folder name may matter.
- If a context configuration exists, it may override both.
For example, if the package is named billing.war and you want the app at /billing, the default behaviour may already be correct.
Step 3: Align the deployment name with the desired URL
If you are using a Tomcat deployment through My App Server, upload or install the application with the name that matches the final URL as closely as possible. This makes updates easier and reduces the chance of misrouting.
Examples:
- Upload crm.war for /crm
- Upload docs.war for /docs
- Upload ROOT.war for the main domain
Step 4: Verify Apache and Tomcat do not conflict
In shared hosting, Apache may already be serving the domain. If Apache has files in the document root and Tomcat is also attached to the same path, the first server layer that handles the request determines the response. This can cause confusion if:
- the app is deployed at the root but Apache still serves a default page
- static files are in one location and the Java app is in another
- rewrite rules send traffic somewhere unexpected
Check the domain settings in the control panel and confirm whether the path should be handled by Apache, Tomcat, or both through proxy rules.
Step 5: Test the final URL directly
After deployment, test the exact path in a browser:
- /
- /app
- /app/
- nested application routes such as /app/login
If the base URL works but internal links fail, the app may be generating absolute links with the wrong context path. In that case, check the application configuration, not only the Tomcat mapping.
How public URL mapping works in My App Server
In the My App Server setup, Java applications run inside your hosting account with control through Plesk. This gives you practical options for Tomcat hosting without needing a separate standalone server administration workflow.
Typical advantages include:
- installing a ready-made Java or Tomcat version with a button
- uploading a custom app server version when needed
- running your own private JVM inside the account
- controlling service start and stop from the panel
- deploying WAR, JSP and servlet applications with a predictable URL
For public URL mapping, the important part is that the app server, the deployed app, and the domain settings all work together. If one layer expects /app but another forwards traffic to /myapp, the result is usually a mismatch, redirects, or 404 responses.
Best practices for clean Tomcat URL mapping
Keep the URL simple
Use short, meaningful paths such as /app, /portal, or /shop. Short URLs are easier to maintain and less likely to break when the app is redeployed.
Avoid frequent path changes
If you change the context path often, bookmarks, links, API clients, and integrations may break. Pick a stable public URL early in the project.
Match the app name with the public path
When the file name, directory name, and public URL all match, deployment becomes easier to understand. This is especially useful in a hosting control panel where release management should stay straightforward.
Use ROOT only when needed
Mapping a Tomcat app to the site root is convenient for a main application, but it can conflict with existing site content. Use ROOT.war only if the domain should serve the Java application as the primary site.
Check trailing slash behaviour
Some applications handle /app and /app/ differently. If users report redirects or broken assets, make sure the app is designed to work with the exact context path and slash format used by Tomcat.
Review generated links and assets
An app may load at the correct URL but still reference CSS, JavaScript or images from the wrong base path. This usually happens when the application is not context-aware. Fixing the public URL mapping alone may not be enough.
Examples of URL mapping scenarios
Scenario 1: WAR file matches the URL
You upload inventory.war and want the app at https://domain.com/inventory. Tomcat deploys it under that path automatically. This is the simplest and most reliable case.
Scenario 2: App should open on the main domain
You want the Java application to replace the default site and load at https://domain.com/. In this case, the deployment should usually be named ROOT.war, or the context root should be configured to the root path. Make sure no other content on the same domain is expected to stay at the same location.
Scenario 3: Apache serves the site, Tomcat serves only one section
The main site uses static or PHP content, but the Java application should be available at https://domain.com/app. Apache serves the domain and forwards only the /app path to Tomcat. This is a common mixed-stack setup in hosted environments.
Scenario 4: Separate subdomain for the Java app
You want https://app.domain.com/ to open the Tomcat app. This is a clean option when the application is logically separate from the main website. It also makes testing and release management easier.
Troubleshooting wrong Tomcat public URLs
The app opens at the wrong path
Check the WAR file name, context file, and any Apache proxy rules. One of them is likely pointing to a different path than expected.
The browser shows 404 errors after deployment
This often means the URL path does not match the deployed context root. Confirm that the application is installed under the exact name or context you are trying to open.
The homepage works but internal pages do not
This usually points to an application-level base path problem. The app may be generating links for a different context root than the one actually used in Tomcat.
Another site appears instead of the Tomcat app
Apache or the default hosting document root may still be serving the domain. Review domain settings in the control panel and confirm which service handles the request first.
Changes do not appear after redeploying
Clear any browser cache, then check whether the old WAR, old context file, or unpacked directory is still present. In Tomcat deployments, leftover files can cause the server to keep using an older mapping.
Practical checklist before going live
- Confirm the desired public URL.
- Make sure the WAR or context name matches that URL.
- Check that Apache is not overriding the route.
- Verify the application opens at both /app and /app/ if relevant.
- Test links, static assets, login pages and API endpoints.
- Review the Plesk service status if the app does not respond.
- Restart the Tomcat service only if needed after a configuration change.
FAQ
What is the difference between a context root and a public URL?
The context root is the path Tomcat uses internally for the application. The public URL is the browser address users type. In many setups they are the same, but Apache, proxy rules or rewrite rules can change the final public path.
Can I map a Tomcat app to the domain root?
Yes. A root mapping is usually done with ROOT.war or an explicit root context. This is useful when the Java app should be the main site content.
Why does my WAR deploy under a different name?
Tomcat often uses the WAR file name as the context path. If the file name is not what you expected, rename the package or define the context explicitly.
Can Apache and Tomcat share the same domain?
Yes. Apache can serve static content and forward only the Java application path to Tomcat. This is common in hosted environments where one account needs both a website and a Java application.
What should I do if my app needs a fixed URL after updates?
Use a stable context path and avoid changing the WAR file name during releases. If your hosting setup supports it, use a dedicated context configuration so the URL stays constant even when the deployment package changes.
Does My App Server support custom Java and Tomcat versions?
Yes. In the My App Server model, you can use ready-made Java and Tomcat versions or upload and configure a custom app server version when your project requires it. This is useful for keeping the deployment aligned with the app’s expected runtime.
Conclusion
To map a Tomcat app to the right public URL, make sure the context root, deployment name and hosting routing all point to the same path. In a Plesk-based Java hosting setup with My App Server, the most reliable approach is to keep the URL simple, verify the domain routing, and test the app exactly where users will access it. Whether you deploy a WAR, serve the app through Apache, or run it under a private JVM, a consistent path structure helps prevent 404 errors and makes future releases much easier to manage.