When you publish more than one Tomcat app in the same hosting account, the main things to review are the context path, the public URL, the Apache-to-Tomcat mapping, and whether each application uses its own data, logs, and Java settings. In a managed hosting environment with Plesk and a service like My App Server, these checks help prevent one app from overwriting another, sending traffic to the wrong context, or exposing the wrong files.
For small and medium Java hosting setups, it is common to run a private Tomcat instance inside a shared hosting account. That approach works well for WAR, JSP, and servlet applications, but only if each deployment is planned carefully. The same Tomcat server can host multiple apps, yet each one must have a clear path, a unique context root, and the right public URL behaviour.
What changes when you deploy more than one Tomcat app
Tomcat can serve several applications at once, but each one is identified by its context. The context is the part of the URL that points to a specific app, such as /shop, /portal, or /api. If two applications are deployed with the same context path, one of them may replace the other, or the last deployed version may become active.
In a hosting panel such as Plesk, the deployment workflow is usually simplified, but the same rules still apply. You should review:
- the application name and deployment folder
- the context root used by Tomcat
- the public URL exposed through Apache or the control panel
- the Java version and JVM settings used by the app
- the app’s configuration files, uploads, and persistent storage
If your environment uses My App Server, each Tomcat app can run under the same hosting account but still behave like a separate service endpoint. That makes it practical to host multiple Java applications without needing a complex enterprise stack.
Review the context path before publishing
The most important item to verify is the Tomcat context path. This is the base path where the app is available. For example, if your app is deployed as /blog, users access it at https://example.com/blog.
Before publishing a second app, check whether the first one already uses the same path. Common mistakes include:
- deploying two WAR files with the same filename
- using the same context root in two different deployment directories
- leaving a default ROOT application in place when you want a custom public URL
- reusing an old context name after a migration
If you want separate applications, assign each one a separate context root. A clear naming pattern also helps during updates. For example:
- /app1 for the first application
- /app2 for the second application
- /admin for an internal interface
- /api for a service endpoint
Keep the context path short, predictable, and easy to document. This reduces confusion during support, testing, and future releases.
Check whether ROOT is already used
Tomcat treats the ROOT application as the site shown at the domain itself, without any extra path. If more than one app is being deployed, only one of them can safely act as the root application.
Review the following:
- is there an existing ROOT web application?
- should the new app be published at the domain root or in a subpath?
- will a second app need a separate subdomain instead of a path under the same domain?
If your first app already serves the main website, the safer choice for the second app is usually a dedicated context path such as /portal or /staging.
Confirm the public URL and Apache mapping
In hosting environments where Apache sits in front of Tomcat, the public URL is not always the same as the internal Tomcat context. Apache may rewrite, proxy, or forward requests to the Java service. That means the app can work in Tomcat but still be unreachable or incorrect on the public domain if the mapping is not reviewed.
Before publishing a second app, check:
- the domain or subdomain used by the app
- the document root or proxy target in the control panel
- whether Apache forwards only a specific path to Tomcat
- if any rewrite rules already send traffic to the first app
For example, one application may be available at https://domain.com/app1 while another runs at https://domain.com/app2. If both rely on the same Apache rules, make sure the rules do not overlap. A small conflict in the virtual host or proxy configuration can cause one application to capture requests meant for the other.
Subdomain versus subpath
When you publish multiple Tomcat apps, consider whether each one should use a separate subdomain or a path under the same domain.
Use a subpath when:
- the apps belong to the same project
- they share the same domain branding
- you want simple navigation between them
Use a subdomain when:
- the applications are separate products
- they need different cookies or session boundaries
- you want cleaner isolation at the URL level
From a hosting perspective, both approaches can work well in My App Server, but the most important point is consistency. Pick one URL model and apply it to all deployments of that project.
Review WAR filenames and deployment folders
In Tomcat, the WAR filename can influence the context path if no custom context is set. That is why you should review file names before uploading a second application. For example, shop.war often becomes available at /shop.
When multiple applications are stored in the same account, use separate folders and clear names. Avoid generic names such as app.war, new.war, or test.war unless they are temporary. These names can lead to mistakes later, especially during release updates.
Good practice:
- use one deployment folder per app
- store each WAR file under a meaningful name
- keep backup archives outside the active deployment directory
- remove old unpacked copies if they are no longer needed
If the hosting platform allows you to manage Tomcat through Plesk, use the panel to verify which file is tied to which context. This is faster and safer than guessing based on filenames alone.
Check application-specific configuration
Multiple Tomcat apps often need different settings, even if they run in the same JVM. Before publishing a new app, review whether it has its own:
- database connection string
- environment variables
- JNDI resources
- mail settings
- file upload path
- cache directory
A common error is to copy a working WAR and forget that the second app still points to the first app’s database or storage folder. This can cause data mixing, failed logins, or permission problems.
If your hosting plan uses a private JVM per app server service, check whether the app is expected to share the same Java process or whether it has a separate runtime profile. For smaller hosting setups, a separate JVM for the service is often enough to keep applications isolated without introducing extra complexity.
Review external files and persistence
Not all application data lives inside the WAR. Many apps need persistent folders for uploads, generated reports, or runtime files. When you publish more than one app, confirm that each one uses its own storage location.
Examples include:
- uploaded images
- temporary exports
- log archives
- session-related files
- user-generated documents
If two applications write to the same directory, one release can overwrite the other’s files. That is especially risky after a redeploy.
Review Java version compatibility
With My App Server, you may be able to select from preinstalled Java and Tomcat versions or upload and configure a custom one. Before publishing a second app, make sure the target Java version matches the application’s requirements.
Review the following:
- which Java version the app needs
- whether both apps can run on the same JVM version
- if the second app depends on newer libraries or a different servlet specification
- whether startup parameters or memory needs are different
It is common for one application to work on an older Java runtime while another needs a newer one. If both are hosted in the same control panel account, the selected service version should be documented clearly before release.
Review memory, startup, and service limits
Running more than one Tomcat app on a single hosting service means the available memory and service limits are shared. Even in a private JVM setup, each additional app increases the load on the environment.
Before publishing, check:
- heap usage expected by each app
- number of active sessions
- background jobs or scheduled tasks
- upload or processing spikes during peak usage
- overall service limits in the hosting plan
If one application is much heavier than the other, consider separating the release schedule or reviewing whether it should use a different app server instance. The goal is not enterprise-scale clustering, but stable shared hosting behaviour.
Review session, cookie, and login behaviour
When two applications share a domain, browser cookies and sessions can overlap if the apps are not configured carefully. This matters especially when both apps use the same parent domain or similar paths.
Check the following before publishing:
- cookie path settings
- session timeout values
- single sign-on assumptions
- cross-app redirects
If one app logs users in at /portal and another runs at /admin, make sure each app stores its session in its own scope. Otherwise, logging into one app may not behave as expected when users open the other app in the same browser.
Review logs, monitoring, and troubleshooting access
Multiple applications are easier to support when each one has separate logs or clearly separated log sections. Before publishing a new app, confirm where its standard output, error logs, and access-related logs will go.
Useful checks include:
- log file names are unique per app
- the log directory is writable
- old logs from previous deployments are archived
- the control panel exposes the service status clearly
In a Plesk-based workflow, being able to control the app server service and review its usage makes it much easier to diagnose a wrong context path, an invalid rewrite rule, or a failed startup after deployment.
Practical deployment checklist for more than one Tomcat app
Use this checklist before you publish a second application in the same Tomcat hosting account:
- Confirm the context path for each app.
- Verify that only one app uses the ROOT context.
- Check the public URL and Apache mapping.
- Make sure WAR filenames and folders are unique.
- Review Java version compatibility.
- Confirm database and file storage separation.
- Check session and cookie scope.
- Review memory and service limits.
- Verify logging for each app.
- Test the final URL in a browser after deployment.
If you follow these steps, you reduce the risk of one Tomcat app interrupting another after release.
Example deployment scenarios
Two apps under the same domain
You may have a customer portal at /portal and an internal reporting tool at /reports. In this case, both apps can share the same domain, but they should have separate contexts, separate databases, and separate log files. Apache should route each path correctly.
One app at the root, another under a subpath
If the main site is the root application, the second app should usually be published at a different path, such as /app. This avoids replacing the main site and keeps the public URL structure clear.
One app per subdomain
If the applications are unrelated, using separate subdomains can simplify access and reduce URL conflicts. Each subdomain can still run through the same managed hosting account, while keeping the apps easier to manage at the public URL level.
Common mistakes to avoid
- uploading a second WAR file with the same name as the first one
- forgetting that ROOT can only belong to one active app
- changing the Tomcat context but not updating Apache rules
- reusing the same database schema for two different applications
- keeping old unpacked app folders after redeploy
- assuming the public URL will match the internal deployment path automatically
- ignoring cookie and session overlap on the same domain
These issues are usually simple to fix, but they are easier to avoid when reviewed before publishing.
FAQ
Can two Tomcat applications use the same context path?
No. If two apps use the same context path, one can overwrite or replace the other. Each application should have its own unique context.
Can I run multiple Tomcat apps in one hosting account?
Yes. In a managed Java hosting setup with My App Server, multiple Tomcat apps can run in the same account as long as paths, resources, and service settings are planned correctly.
Do I need a separate JVM for each app?
Not always. Some setups share the same service runtime, while others use a private JVM per app server service. The important point is to confirm which model your hosting account uses and to review resource use accordingly.
Why does the app work in Tomcat but not on the public URL?
This usually means the Apache mapping, reverse proxy rule, or domain configuration does not match the Tomcat context. Check the public path, rewrite rules, and proxy target in the control panel.
What is the safest way to publish a second app?
The safest approach is to assign a new context path, verify Apache or Plesk routing, separate persistent data, and test the final URL before making it live.
Can two apps share the same database?
They can, but it is usually better to keep them separate unless they are designed to work together. Sharing a database can make upgrades, troubleshooting, and data isolation more difficult.
Conclusion
When you publish more than one Tomcat app, the key checks are simple but important: unique context paths, correct public URLs, separate application data, and compatible Java settings. In a hosting environment with Plesk and My App Server, these steps help you run multiple Java applications safely within one hosting account without unnecessary complexity.
By reviewing paths, contexts, Apache mapping, and service limits before release, you make each Tomcat deployment more predictable and easier to support. That is the best way to keep Java hosting stable for WAR, JSP, and servlet applications.