If you are publishing more than one Java app under the same hosting account, the most important thing to review is how each application resolves its public URL, context root, Java runtime, and Tomcat service settings. In a Plesk-based Java hosting setup with My App Server, this matters because two apps can coexist safely only if their paths do not overlap and their deployment rules are clear.
For UK-based hosting customers, the same principles apply whether you are running a small JSP site, a servlet-based application, or multiple WAR files on one private JVM. A good release plan should confirm where each app will be accessed, whether it needs its own context path, and how Apache and Tomcat will route the request. If those details are not checked before publishing, common problems include 404 errors, the wrong app opening at the root URL, static files being served unexpectedly, or one application replacing another.
What you should confirm before publishing multiple Java apps
Before uploading a second or third Java application, review the following points for each one:
- its public URL or domain name
- its context root in Tomcat
- the app directory or WAR name used during deploy
- whether it should run at the site root or under a subpath
- the Java version it requires
- whether it uses the same Tomcat instance as the other apps
- any Apache rewrite or proxy rules that affect routing
- session, cookie, and login path behaviour
- static file locations and upload paths
In a managed hosting environment, this review is usually quicker than troubleshooting after release. It also helps avoid accidental overlap between apps that use similar names or folder structures.
Review the public URL for every app
The first step is to decide how each Java app will be reached publicly. One app may live on the main domain, another on a subdomain, and a third under a path such as /app1 or /portal. The public URL should be written down before deployment, not decided after the app is already live.
Typical options include:
- Root URL - the app is meant to open at https://example.co.uk/
- Subpath - the app is accessed at https://example.co.uk/shop/
- Subdomain - the app is accessed at https://app.example.co.uk/
- Separate domain - useful when applications must be isolated at the URL level
If more than one app shares the same domain, it is usually safer to separate them by path or subdomain. Otherwise, one deployment may overwrite the public entry point of another.
Check the Tomcat context root for each deployment
In Tomcat hosting, the context root is the path where the app is mounted. This is often defined by the WAR file name, deployment folder name, or configuration inside Tomcat. For example, myapp.war may deploy to /myapp, while a WAR named ROOT.war can become the site root.
When multiple Java apps are deployed in one hosting account, review these context rules carefully:
- Do not let two applications claim the same context root.
- Confirm whether the app is meant to be the root application or a subpath application.
- Check whether a deployed folder name differs from the public path you want.
- Make sure the app’s internal links match the actual context root.
If an app is designed for / but deployed as /app1, absolute links and redirects may fail unless the application is context-aware. If it is not, you may need to adjust configuration, rebuild links, or change the deployment name.
Understand how Apache and Tomcat work together
In a Plesk hosting environment, Apache often serves as the front layer while Tomcat handles the Java application itself. This arrangement is practical for Java hosting, JSP hosting, and servlet hosting, but it means you must review how requests are passed to Tomcat.
When publishing multiple apps, check whether Apache is:
- forwarding traffic to one shared Tomcat instance
- mapping each app to a different path or subdomain
- serving static files directly while Tomcat handles dynamic content
- using rewrite rules that may affect URLs or trailing slashes
If Apache rewrite rules are too broad, one app can capture traffic intended for another app. This is especially common when several apps use similar route names such as /login, /api, or /admin.
Review app names, WAR names and folder names
Deployment names matter more than many users expect. In a Java hosting platform, the WAR file name or unpacked directory name may define the public path. That means a harmless-looking file rename can change how the app is accessed.
Before you publish, confirm the naming convention for each application:
- Does the WAR name define the URL path?
- Does the deployment folder name matter?
- Will a new upload replace an existing app?
- Is the app expected to deploy as ROOT?
A practical rule is to use clear, unique names for every application. For example, crm.war, billing.war, and portal.war are easier to manage than generic names that could collide during release.
Verify whether each app needs its own JVM or Tomcat service
With My App Server, customers can manage a private JVM and Apache Tomcat inside a shared hosting account, which is useful for controlled Java deployments. If you are publishing more than one app, review whether they should share the same service or run separately.
Sharing one Tomcat instance may be fine when the applications are closely related and use the same Java version and resource profile. Separate services are better when the apps:
- need different Java versions
- must be restarted independently
- have different release schedules
- should not share the same memory or session environment
- use different context paths or domains
On a managed hosting platform, keeping the service structure simple makes support and maintenance easier. It also reduces the chance that one deployment affects another during restart or update.
Confirm Java version compatibility
If your account supports multiple Java versions, review the runtime required by each application before deployment. A Java app that runs correctly on one version may fail on another because of library differences, deprecated APIs, or build settings.
Check the following for each app:
- minimum Java version required by the build
- whether it depends on a newer or older Tomcat release
- library compatibility with the selected JVM
- build target version used by your compiler
When multiple apps are deployed on the same hosting account, it is a mistake to assume they all need the same runtime. Review each one independently, especially if one app is legacy and another is newly built.
Check internal links, redirects and base URLs
Many Java applications work correctly until the public path changes. If one app is deployed at the root and another under a subpath, hardcoded links can break. This applies to redirects, form submissions, asset references and API calls.
Review these elements carefully:
- absolute links starting with /
- hardcoded domain references
- login redirects after authentication
- links to CSS, JavaScript and images
- REST API base paths
- trailing slash handling
If the app was developed for a fixed domain or single-root deployment, it may need configuration changes before it can live under a different path. This is one of the most common issues when publishing more than one app on the same hosting account.
Review session and cookie scope
When two applications share the same domain, cookies and sessions can overlap if they are not configured properly. This is particularly important for apps that use login systems or remember user state.
Before publishing, verify:
- cookie names are unique where necessary
- cookie paths do not overlap incorrectly
- session timeouts are suitable for each app
- authentication redirects return to the correct URL
If both applications use the same cookie name and the same domain path, a user can be logged into the wrong app state or lose access after switching between apps. For multi-app hosting, unique session behaviour is often essential.
Review static file handling and public assets
Java apps often include static files such as CSS, images, JavaScript, downloads and uploaded documents. When more than one app is published, you should confirm where these files live and how they are served.
Check whether static files are:
- served by Apache directly
- stored inside the app package
- stored in a separate directory
- protected by application logic
One common mistake is placing public assets in a shared folder and then reusing the same file names in another app. That can cause unexpected overwrites or the wrong content being displayed. Keep each application’s public files separated whenever possible.
Use a simple pre-publish checklist
Before you release a second Java app, run through this checklist in Plesk or your hosting control panel:
- Confirm the intended public URL.
- Verify the context root or subpath.
- Check that the WAR name does not collide with another deployment.
- Confirm the Java version and Tomcat compatibility.
- Review Apache rewrite and proxy rules.
- Validate links, redirects and static file paths.
- Test authentication, cookies and sessions.
- Make sure the previous app will not be overwritten.
- Confirm whether a restart is required for the Tomcat service.
- Test the live URL before announcing the release.
This list is especially useful in managed Java hosting because it reduces the chance of release-day routing problems. Even a small app benefits from a clear deployment checklist.
Common issues when publishing multiple Java apps
One app opens instead of another
This usually means both applications were deployed to the same context root or one app replaced the root deployment. Check the WAR name, folder name and Tomcat mapping.
404 errors on links or images
This often happens when the app was built for a different base path. Review internal links, static asset URLs and any hardcoded redirects.
Login works in one app but not the other
This may be caused by cookie overlap, session scope issues, or shared domain settings. Make cookies unique and review path settings.
A release overwrote an existing application
Using the same deployment name or root mapping can replace a previously published app. Always use unique names and verify the target path before upload.
The app works in test but fails live
Live deployments often differ because Apache routing, context root, or Java version settings are not identical to the test environment. Compare both setups carefully.
Example deployment plan for two apps
Here is a simple example of how to plan two Java applications in one hosting account:
- App A - public URL: https://example.co.uk/portal/, deployed as portal.war, uses Java 17
- App B - public URL: https://app.example.co.uk/, deployed as ROOT.war on a separate app server, uses Java 11
In this setup, the two apps do not compete for the same path. Their URLs are easy to remember, and any future updates can be handled independently. That is usually the cleanest approach when publishing more than one Java app on shared hosting.
When to choose a separate domain or subdomain
If the apps are unrelated, have different user groups, or must not share cookies and paths, a separate subdomain is often easier than placing everything under one main domain. It also makes testing and maintenance simpler.
A separate subdomain is worth considering when:
- the apps have different branding
- each app has its own login area
- one app is customer-facing and another is internal
- the apps should be deployed independently
- you want simpler URL routing
For many Java hosting customers, this is the most practical way to avoid context collisions without introducing unnecessary complexity.
FAQ
Can I publish two Java apps under the same domain?
Yes. The key is to give each app a different context root, path or subdomain so they do not conflict in Apache or Tomcat.
Does the WAR file name affect the public URL?
In many Tomcat deployments, yes. The WAR name often becomes the context path unless the app is deployed as ROOT or configured otherwise.
What is the safest way to run multiple Java apps in one hosting account?
The safest approach is to keep each app on a unique path or subdomain, verify the Java version it needs, and test the final URL before going live.
Can two apps share one Tomcat instance?
They can, if they are compatible and do not need separate runtime settings. However, if their versions, release cycles or session behaviour differ, separate services are usually easier to manage.
Why do my links break after deployment?
This usually means the app was built with hardcoded paths or an incorrect base URL. Review internal links, redirects and asset references before publishing.
Should I use ROOT.war for every app?
No. Only one application can normally own the root path at a time. Other apps should use distinct context roots unless they are deployed on separate domains or services.
Conclusion
When publishing more than one Java app, the main job is to review paths, contexts and public URLs before deployment. In a Plesk-based My App Server setup, that means checking the context root, the WAR name, Apache routing, Java version compatibility and any session or cookie overlap.
If each application has a clear URL plan and a unique deployment target, multi-app Java hosting stays manageable and reliable. That is the simplest way to avoid path conflicts, reduce deployment risk and keep every app accessible at the right public address.