When you host a Java application on Tomcat and point a domain at it, two different mappings need to work together: the domain name mapping in your hosting panel, and the application path mapping inside Tomcat. If either side is wrong, the site may load the wrong application, return a 404, or show content at an unexpected URL such as /app instead of the domain root.
On managed Tomcat hosting with a control panel such as Plesk, this usually means understanding how the public domain, document root, Tomcat context path, and any reverse proxy or Apache rules fit together. In the ITA My App Server environment, this is especially useful for small and medium Java, JSP, servlet, and WAR deployments where you want a clean public URL and a predictable application path.
In practice, the domain answers the question “which website address should visitors use?”, while the application path answers “which Tomcat application should serve that address?”. When configured well, your application can open at the domain root, a subdomain, or a subfolder depending on your setup.
How domain paths and application paths are different
A domain path is the public URL path that a visitor types in the browser, for example:
- https://example.co.uk/
- https://example.co.uk/shop
- https://app.example.co.uk/
An application path is the path Tomcat uses internally for the deployed app. In Tomcat terms, this is usually called the context path. Examples include:
- / for the root application
- /myapp for an app under a path
- /api for an API deployment
These paths do not always have to match exactly, but they should be aligned intentionally. If the public domain points to a document root that does not match the Tomcat app, you may get the hosting platform’s default page, a directory listing, or a 404 error instead of the Java application.
How Tomcat hosting usually handles public URLs
In a typical Tomcat setup on managed hosting, the request flow works like this:
- The domain resolves in DNS to the hosting account.
- Apache or the hosting control panel receives the HTTP or HTTPS request.
- The request is passed to Tomcat through the platform’s integration layer.
- Tomcat matches the request to a deployed application by context path.
- The app generates the response for that public URL.
With ITA My App Server, this process is designed to be manageable inside the hosting account, so you can install a Tomcat version, choose a Java version, and manage the app service through Plesk. That makes it practical for WAR, JSP, and servlet applications that need their own runtime without managing a full external server.
Root domain versus subpath deployment
There are two common ways to publish a Tomcat app:
- Domain root: the app opens at https://example.co.uk/
- Subpath: the app opens at https://example.co.uk/app/
Root deployment is often simpler for public websites. Subpath deployment is useful when the domain hosts multiple services, such as a main website and a separate Java app.
For example:
- https://example.co.uk/ → marketing website
- https://example.co.uk/portal/ → Tomcat application
- https://api.example.co.uk/ → REST API
What happens when the domain and application path do not match
Mismatch is one of the most common causes of confusion on Tomcat hosting. A few examples:
- The domain points to the correct hosting account, but Tomcat deploys the app under /myapp while users visit /.
- The app is deployed at the root, but Apache or the panel sends the request to a different directory.
- The browser requests /shop, but the application only knows routes under /.
- The app generates links with the wrong base path after being moved to a new domain or subfolder.
Typical symptoms include:
- 404 Not Found
- Tomcat default page appears instead of the app
- Static resources such as CSS, JavaScript, or images fail to load
- Login redirects loop back to the wrong URL
- Generated links point to the old path
In most cases, the fix is not “Tomcat is broken” but rather that the public URL and the app’s context path are not aligned.
Mapping a domain to a Tomcat application in Plesk
In a Plesk-based hosting environment, domain mapping usually starts with the domain or subdomain assignment in the control panel, then continues with the Java application configuration in My App Server.
Common setup pattern
- Add or select the domain in the hosting panel.
- Make sure DNS points to the hosting service.
- Enable SSL if the site will use HTTPS.
- Install or select the required Tomcat version in My App Server.
- Deploy the application as a WAR or configure the app directory.
- Set the public path or context path as needed.
- Test the site using the exact URL you expect visitors to use.
When the app is meant to live at the domain root, make sure the deployment is configured for / rather than a named subfolder. When the app should live under a path, check that Apache, the panel, and Tomcat all agree on that path.
Practical examples
Example 1: Root website
- Public URL: https://www.example.co.uk/
- Tomcat context path: /
- Use case: main web application, landing page, or portal
Example 2: App under a subfolder
- Public URL: https://www.example.co.uk/app/
- Tomcat context path: /app
- Use case: internal tool, customer dashboard, or admin app
Example 3: Separate subdomain
- Public URL: https://portal.example.co.uk/
- Tomcat context path: /
- Use case: dedicated application with its own SSL and routing
How Tomcat context paths work
Tomcat uses the context path to decide which application should respond to a request. If a WAR file is deployed as shop.war, the default context path may become /shop. If you want the app at the root, you usually need root deployment or a configuration that explicitly serves it from /.
Key idea: file name can affect URL path
In many Tomcat setups, the deployment name influences the public path:
- shop.war → /shop
- portal.war → /portal
- Root deployment configuration → /
This is why the same application may work at one URL in staging and another in production if it is deployed differently. Always check the actual context path after deployment.
Why absolute links can break
If your application is built with hardcoded links such as /login or /images/logo.png, those links may fail when the app is moved from root to a subfolder. In a subpath deployment, links should be generated relative to the application context or built using the correct base URL.
This is especially important when hosting a Java application in a shared account, where you may switch between domain root, subdomain, and subfolder deployments during testing or go-live changes.
How to choose between root, subdomain, and subfolder
The right structure depends on how you want users to access the app and how the website is organised.
Use the domain root when
- The Java app is the main website.
- You want a clean URL with no extra path.
- There is only one application to publish for the domain.
Use a subdomain when
- The app is separate from the main website.
- You want clearer operational separation.
- You need a dedicated SSL certificate and independent deployment path.
Use a subfolder when
- The app is part of a larger site.
- You want to keep one domain but publish multiple services.
- The application is not sensitive to being hosted under a path.
For many small and medium Java deployments, a subdomain is often the easiest option if the app expects root-level links. A subfolder can work well too, but only if the application handles its base path correctly.
Steps to make domain paths and application paths work together
1. Confirm the public domain or subdomain
Make sure the domain exists in the hosting panel and that DNS is pointing to the correct hosting service. If the browser cannot reach the right account, Tomcat never receives the request.
2. Check the document root or public target
In Plesk and similar control panels, the domain may have a document root or a public directory. For Java hosting, this should match the platform’s Tomcat integration and the location expected by My App Server.
3. Verify the Tomcat deployment path
Check whether the app is deployed at:
- / root
- /app
- /service
If you deploy a WAR, confirm whether the file name or deployment rule sets the public path automatically.
4. Align application-generated URLs
Update the app so it generates correct links, redirects, and asset URLs for the chosen path. This is essential after moving an app from local testing to hosted Tomcat.
5. Test both HTTP and HTTPS
Because public URLs often switch to HTTPS after SSL setup, test that the application works the same way on the secure URL. Redirects, cookies, and login flows should all use the final public address.
6. Review Apache or proxy rules if used
If the hosting platform uses Apache in front of Tomcat, confirm that rewrite or proxy rules are not sending traffic to the wrong place. This is especially relevant if you are mapping a friendly URL to a Java app under a hidden backend path.
Common configuration mistakes
- Using the wrong context path and expecting the app to open at a different URL.
- Hardcoding root-relative links in an app that is actually deployed under a subfolder.
- Forgetting SSL changes after switching the domain to HTTPS.
- Leaving old redirects in place after moving the app to a new domain or path.
- Assuming the WAR file name has no effect on the deployed URL.
- Mixing Apache document root logic with Tomcat context logic without checking the hosting control panel setup.
Best practices for Tomcat hosting URL mapping
To keep domain and application paths stable on managed Java hosting:
- Decide the final public URL before deployment.
- Prefer one clear mapping per application.
- Use consistent naming for WAR files and deployment folders.
- Keep links and redirects relative to the application context.
- Test the site after every change to domain, SSL, or path.
- Document the intended public URL for future maintenance.
If you manage more than one application on the same hosting account, use separate subdomains or clearly separated paths. This reduces the risk of conflicting URLs and makes future updates easier.
How My App Server helps in this setup
ITA My App Server is designed for practical Java hosting inside a shared hosting account, giving you control over a private Tomcat or JVM environment through Plesk. That makes it suitable for hosted Java applications that need:
- a selectable Java version
- one or more Tomcat versions available for installation
- service control from the panel
- deployment of WAR, JSP, and servlet-based apps
- an application-specific runtime instead of a generic web folder
For domain and path mapping, this matters because you can manage the app service and the public URL from the same hosting account rather than relying on a separate external server setup. It is a good fit for standard Java hosting tasks, but it is not intended as a heavy enterprise cluster platform.
FAQ
Why does my Tomcat app work on a subdomain but not on the main domain?
The subdomain may be mapped correctly to the app, while the main domain is still pointing to a different document root or another application. Check the domain assignment in the control panel and confirm the Tomcat context path.
Can I run a Tomcat app at the root of the domain?
Yes, if the hosting setup supports root deployment and the application is configured for the / context path. This is common when the Java app is the primary site for that domain.
Why do images and CSS stop loading after moving the app to a folder?
That usually means the app uses root-relative links that no longer match the new path. The application should generate URLs using the correct base path or context.
What is the difference between a domain path and a Tomcat context path?
The domain path is the URL the visitor sees in the browser. The Tomcat context path is the internal application path that determines which deployed app answers the request.
Does the WAR file name always become the URL path?
Often, yes, but not always. In many deployments, the WAR name influences the context path. However, platform rules or custom configuration can override that behavior.
Should I use a subdomain or a subfolder for a Java app?
Use a subdomain if you want clean separation and fewer path-related issues. Use a subfolder if the app is part of a broader site and is designed to work under that path.
Conclusion
Domain paths and application paths work together by dividing responsibility between the public URL and the Tomcat deployment context. On managed Tomcat hosting, especially in a Plesk-based environment with My App Server, correct mapping ensures that visitors reach the right Java application at the right address.
If you choose the right public URL, deploy the app to the matching context path, and verify how links are generated inside the application, you can avoid most of the common problems with 404 errors, broken assets, and redirect loops. For Java, JSP, servlet, and WAR hosting, that alignment is one of the most important parts of a stable go-live setup.