When you use Tomcat hosting in Plesk, a subdomain is usually treated as a separate website entry, but it can still point to the same Tomcat service, the same Java application, or a different deployment altogether. This makes subdomains a practical way to split applications by purpose, such as app.example.co.uk, api.example.co.uk, or test.example.co.uk, while keeping everything manageable from the Plesk control panel.
In a managed Java hosting setup such as My App Server, the main idea is simple: Plesk handles the domain and subdomain configuration, while Tomcat runs your Java application behind the scenes. You can use one Tomcat instance for multiple hostnames, or create a separate service and deployment for each subdomain if your setup requires it. The right approach depends on how your application is built, how you route requests, and how much isolation you need.
How subdomains map to Tomcat hosting in Plesk
A subdomain is a DNS and hosting label that sits under your main domain. In Plesk, a subdomain often has its own document root, web hosting settings, logs, and SSL certificate options. With Tomcat hosting, that subdomain can also be linked to a Java application served by Apache Tomcat or a private JVM.
For example:
- example.co.uk may serve your main website or landing page.
- app.example.co.uk may point to a JSP or servlet application.
- admin.example.co.uk may be used for an internal tool or admin panel.
- api.example.co.uk may expose a Java backend.
In practice, the subdomain itself does not “run Tomcat.” Instead, Plesk directs traffic for that hostname to the correct hosting configuration, and Tomcat handles the application request if the subdomain is assigned to a Java app server. In a My App Server environment, this can be done through the Plesk extension where you install, manage, and connect a private Tomcat instance to the desired domain or subdomain.
Typical ways to use subdomains with Tomcat
1. One Tomcat instance for multiple subdomains
This is useful when you want to keep a single Java runtime and serve different sections of your service through different hostnames. For example, a single Tomcat deployment can answer requests for both app.example.co.uk and www.example.co.uk if your application is configured to accept both hostnames.
This approach is often chosen when:
- The same application should appear under more than one hostname.
- You want a simple deployment model.
- The subdomains are just different entry points to the same codebase.
2. Separate Tomcat deployments per subdomain
Some hosting users prefer to isolate applications by subdomain. For example, you may deploy one WAR file to app.example.co.uk and another to staging.example.co.uk. Each can have its own Java version, service settings, and deployment path where supported by the hosting plan and Plesk extension.
This is often better when:
- You want testing and production separated.
- Different applications use different Java requirements.
- You need cleaner maintenance and easier troubleshooting.
3. Subdomain as a reverse proxy entry to Tomcat
In some configurations, Apache or Plesk may serve the hostname first and proxy requests to Tomcat behind the scenes. This is common in hosting setups where a web server sits in front of the Java application. The subdomain remains the public address, while Tomcat handles the application process.
This can help with:
- Serving static content efficiently.
- Keeping application routing predictable.
- Combining standard website settings with Java app hosting.
What happens when you create a subdomain in Plesk
When you add a subdomain in Plesk, the panel usually creates a separate hosting object under the main domain. Depending on your hosting setup, you may be able to configure:
- Document root
- Hosting type
- SSL/TLS certificate
- PHP or web server settings
- Logs
- Tomcat or Java app server assignment
If your hosting account includes My App Server, you can then connect the subdomain to a Java application. That may mean installing a Tomcat service, selecting a Java version, and deploying your application package, such as a WAR file. In a managed environment, this is usually done directly from the Plesk interface without requiring full server administration.
The important detail is that the subdomain is a hostname-level configuration. Tomcat is the runtime that processes the Java application. Plesk links the two.
Common configuration patterns for UK Tomcat hosting
Subdomain for application access
This is the most common use case. A customer visits app.example.co.uk, and Plesk routes that hostname to the Java application hosted in Tomcat. The same pattern is often used for customer portals, internal dashboards, booking systems, or service tools.
Subdomain for API services
If your Java project exposes an API, a dedicated subdomain such as api.example.co.uk makes the service easier to integrate and manage. It also keeps browser-facing pages separate from application endpoints.
Subdomain for staging or test environments
A staging subdomain such as staging.example.co.uk is useful for testing deployments before release. In Plesk, you can keep the staging environment separate from the live site and assign its own Tomcat service or deployment package.
Subdomain for multiple app areas
Some applications use several subdomains for different parts of the service, such as:
- portal.example.co.uk
- support.example.co.uk
- billing.example.co.uk
This can improve clarity for users and make application routing easier to understand.
How to set up a subdomain for Tomcat hosting in Plesk
The exact steps may vary slightly depending on the hosting plan and the My App Server configuration, but the general process is usually similar.
Step 1: Create the subdomain in Plesk
Open Plesk and go to the domain where you want the subdomain to live. Add a new subdomain such as app or api. Plesk will create a separate hosting entry for it.
At this stage, choose a clear name that matches the role of the application. Short, descriptive names are easier to maintain later.
Step 2: Decide whether the subdomain needs its own application
Ask whether the subdomain will:
- share the same Tomcat instance as another hostname, or
- run its own application deployment.
If the app is small and the same code should answer multiple hostnames, one deployment may be enough. If the subdomain is a separate service, use a separate deployment path or app server entry if your setup supports it.
Step 3: Assign or install the Tomcat service
In a My App Server environment, use the extension to install or select the Tomcat version you need. Some versions are available with one-click installation, while others can be uploaded and configured manually if your application requires a specific runtime.
Choose the Java version carefully. A newer Java version may improve compatibility and features, but your application must support it. If you are running a legacy servlet or JSP app, check the application’s requirements before switching versions.
Step 4: Deploy the application
Upload the WAR file or application package to the correct deployment location for the subdomain. If the app is already packaged for Tomcat, deploy it to the service linked with that subdomain. In many setups, the application will start automatically after deployment or after a service restart.
Useful checks during deployment:
- Correct context path
- Matching hostname in the application config
- Valid Java version
- Correct file permissions
- Enough resource limits for the app
Step 5: Configure DNS and SSL
Make sure the subdomain resolves to the hosting account. If DNS is managed elsewhere, add the relevant A or CNAME record. Then issue or assign an SSL certificate for the subdomain so traffic can use HTTPS.
For public-facing Java applications, HTTPS is strongly recommended. It helps protect login forms, API calls, and session data.
Step 6: Test the hostname
Open the subdomain in a browser and verify that the Tomcat application responds correctly. If the page does not load as expected, check the hosting settings, logs, and application startup status in Plesk.
Important differences between subdomains and application contexts
In Tomcat, a subdomain is not the same thing as a context path. These two terms are often confused.
- Subdomain = a hostname, such as app.example.co.uk.
- Context path = the application path inside Tomcat, such as /myapp.
For example, if your app is deployed at app.example.co.uk/myapp, the subdomain is the hostname and /myapp is the context path. If you want the application to appear directly at app.example.co.uk, you may need to adjust the Tomcat deployment name or routing rules, depending on how your hosting environment is set up.
This distinction matters because many support questions about “subdomain not working” are actually caused by context path configuration, incorrect deployment naming, or a mismatch between the hostname and the Java application path.
Best practices for Tomcat subdomains in Plesk
- Use one subdomain per purpose so staging, API, and production are easy to identify.
- Keep deployment names consistent with the subdomain or application role.
- Use HTTPS on every public subdomain, especially where logins or forms are involved.
- Check Java compatibility before switching Tomcat or JVM versions.
- Review logs after changes to catch startup or routing issues early.
- Separate testing from live traffic when possible.
- Document which subdomain uses which service to avoid confusion later.
These habits make Plesk administration easier and reduce time spent debugging application routing problems.
Common issues and how to check them
The subdomain opens but Tomcat does not load
This may mean the subdomain is created correctly, but it is not linked to the Java application. Check whether the Tomcat service is installed and running, and confirm that the deployment is assigned to the right hostname.
The page shows a default Plesk or Apache page
This often means the hostname is reaching the web server, but the request is not being forwarded to Tomcat or the app has not been deployed. Verify the hosting type and the application mapping in Plesk.
The subdomain gives a 404 error
A 404 can happen when the hostname is correct but the context path is wrong. Check whether the application is deployed at the expected path and whether the internal links or routing rules match the subdomain.
The application starts on one subdomain but not another
If one hostname works and another does not, compare the configuration for each subdomain. Differences in SSL, DNS, document root, or service assignment may be the reason.
Java version mismatch
Some applications require a specific Java release. If the subdomain is pointing to the right service but the app still fails to start, check the runtime version in My App Server and compare it with the application requirements.
When to use a separate subdomain instead of a subfolder
A subdomain is often the better choice when you want a Java application to behave like a separate service. Compared with a subfolder such as example.co.uk/app, a subdomain offers clearer separation and simpler hostname-based routing.
Choose a subdomain when:
- The Java app is distinct from the main site.
- You need different SSL or DNS handling.
- You want cleaner operational separation.
- You plan to run a staging or API endpoint.
A subfolder may still be suitable for small integrations, but for Tomcat hosting in Plesk, subdomains are often easier to manage and troubleshoot.
How My App Server helps with subdomains
ITA’s My App Server extension is designed for practical Java hosting in Plesk. It gives you a controlled way to install and manage Apache Tomcat or a private JVM inside a shared hosting account, which is helpful when you want Java services without handling a full server stack manually.
For subdomains, that means you can:
- Install a Tomcat version that suits the application.
- Assign the service to the relevant hostname or deployment.
- Manage service control from Plesk.
- Use separate Java runtime setups where needed.
- Deploy JSP, servlet, or WAR-based applications with less friction.
This setup is well suited to small and medium Java applications, internal tools, customer portals, and development or staging environments that need predictable control from the panel.
FAQ
Can one Tomcat installation serve multiple subdomains?
Yes, if the application is configured to accept multiple hostnames and the hosting setup allows it. In other cases, separate deployments may be cleaner.
Does every subdomain need its own Tomcat service?
No. A subdomain can share a Tomcat instance with another hostname, or it can use a separate deployment. The best choice depends on your application structure and isolation needs.
What is the difference between a subdomain and a Tomcat virtual host?
A subdomain is a DNS/hostname entry. A Tomcat virtual host is an application server configuration that responds to a hostname. Plesk connects the hostname to the server-side setup.
Can I run a JSP app on a subdomain in Plesk?
Yes. A JSP or servlet application can be deployed to Tomcat and linked to a subdomain through the Plesk hosting configuration or the My App Server extension.
Do I need a separate SSL certificate for each subdomain?
Usually yes, unless you use a wildcard certificate or a certificate that covers the subdomain. Make sure the certificate matches the hostname you want to secure.
Why does my subdomain show the wrong app?
This usually happens when the hostname is mapped to the wrong deployment, or when the Tomcat context path and hosting settings do not match. Check the subdomain assignment and application path.
Can I use a subdomain for staging and keep the main site live?
Yes. This is a common and recommended approach. A staging subdomain lets you test changes without affecting the live site.
Conclusion
Subdomains are a practical way to structure Tomcat hosting in Plesk. They let you separate applications by hostname, keep staging and production distinct, and manage Java deployments more clearly from the control panel. In a My App Server environment, the subdomain acts as the public entry point while Tomcat or a private JVM runs the application behind it.
If you understand the difference between DNS, Plesk hosting settings, and Tomcat context paths, managing subdomains becomes much easier. For most small and medium Java hosting use cases, this approach gives you a good balance of control, flexibility, and simplicity.