When you use Tomcat hosting in Plesk, subdomains are usually the cleanest way to separate Java applications, test environments, and project areas under the same hosting account. A subdomain such as app.example.com can point to its own document root, its own Tomcat deployment, and, when supported by your hosting setup, its own JVM or application configuration. This makes subdomains a practical choice for JSP sites, servlet applications, WAR deployments, and small to medium Java projects managed through Plesk.
In an ITA managed hosting environment, this is typically handled through My App Server, the Plesk extension used for Java hosting and Tomcat hosting. It allows you to install and manage Apache Tomcat or a private JVM within a shared hosting account, choose from available Java versions, and control the service directly from Plesk. For subdomains, the key point is that Plesk treats each subdomain as a separate hosting object, which means you can map it to a specific application path and publish it independently from the main domain.
How subdomains are mapped in Plesk
In Plesk, a subdomain is not just a DNS label. It is also a hosting entry with its own document root, web server configuration, and application settings. When you create a subdomain, Plesk can assign a separate directory under your subscription, for example:
- example.com for the main site
- app.example.com for a Java application
- test.example.com for a staging or testing environment
This structure is useful for Tomcat hosting because each subdomain can serve a different purpose without interfering with the main website. In practice, you can keep marketing pages on the main domain and run your application on a subdomain that forwards requests to Tomcat.
Subdomain hosting and document roots
Each subdomain has a document root, which is the directory from which web content is served. For standard PHP or static hosting, that directory may contain HTML files. For Java hosting with Tomcat, the document root often works as a web-facing path that is connected to the application server through Plesk and My App Server settings.
Depending on the setup, your Tomcat application may be deployed as a WAR file, expanded into a webapp directory, or attached to a virtual host configuration for the subdomain. The exact method depends on the version and features available in your hosting plan and control panel configuration.
How Tomcat works with a subdomain
Tomcat does not normally serve the domain name directly in the way a simple static web server does. Instead, it processes Java web applications and responds to HTTP requests through a configured connector or proxy setup. In a Plesk hosting environment, the subdomain usually acts as the public address, while Tomcat runs behind the scenes as the application engine.
Typical flow:
- A visitor opens app.example.com.
- Plesk and the web server route the request for that subdomain.
- The request is passed to the Tomcat application or to the Java service configured for that subdomain.
- Tomcat returns the response generated by your JSP, servlet, or Java web application.
This approach keeps the public URL simple while allowing the backend to stay in a managed Java environment.
Common subdomain setups for Tomcat hosting
- Main domain + application subdomain — example.com for the company site, app.example.com for the Java app.
- Staging subdomain — staging.example.com for testing changes before production deployment.
- API subdomain — api.example.com for a servlet-based endpoint or backend service.
- Customer portal subdomain — portal.example.com for login and account access.
Setting up a subdomain for Tomcat in Plesk
If your hosting plan includes Java hosting through My App Server, the usual process is straightforward. The exact menu names may vary depending on the Plesk version and the extension installed on your account, but the general steps are similar.
Step 1: Create the subdomain
In Plesk, add the subdomain from the Domains section. Choose a clear name based on its purpose, such as app, test, or portal. Plesk will create the DNS and hosting entry, and assign a directory for files.
Step 2: Confirm the DNS record
Make sure the subdomain resolves correctly. If your DNS is managed in Plesk, it should create the required record automatically. If DNS is external, add or update the appropriate A or CNAME record so the subdomain points to your hosting service.
Step 3: Open My App Server
Go to the My App Server extension in Plesk. This is where you manage Java hosting features such as Tomcat installation, service control, version selection, and app deployment.
Step 4: Assign the application to the subdomain
Choose the subdomain as the target host or the location for your Java application. Depending on the available options, you may:
- deploy a WAR file to that subdomain
- connect the subdomain to a Tomcat instance
- set an application context path
- choose the Java version for the service
Step 5: Deploy your application
Upload your WAR file or application package through the file manager, FTP, or the deployment workflow supported by your setup. If your app is already prepared for Tomcat, place it in the correct deployment directory and restart the service if needed.
Step 6: Test the subdomain
Open the subdomain in a browser and verify that the app loads correctly. Check the application logs if anything does not work as expected. For Java applications, log inspection is often the fastest way to identify classpath issues, permission problems, missing files, or startup errors.
Using a private JVM for a subdomain
One of the useful features of ITA Java hosting is the ability to run a private JVM inside a shared hosting account. This is especially relevant when you want better separation between applications or a specific Java version for one project.
For subdomain-based hosting, a private JVM can help you:
- run one application without affecting other hosted sites
- choose a Java version that matches your app requirements
- manage Tomcat service settings from Plesk
- keep development, staging, and production apps separated
This is a practical solution for Java hosting, JSP hosting, servlet hosting, and lightweight Tomcat deployments. It is not intended to replace a full enterprise application server cluster, but it is highly useful for day-to-day hosting and application management.
Best practices for subdomains on Tomcat hosting
Good planning makes subdomain-based Java hosting easier to maintain. A few simple practices can help avoid deployment problems later.
Use one subdomain per application
Do not place multiple unrelated Java apps in the same subdomain unless they are part of the same project. Separate subdomains make upgrades, rollbacks, and troubleshooting much easier.
Keep staging separate from production
If you are testing new code, use a separate subdomain such as staging.example.com. This reduces the risk of exposing unfinished features on the live site.
Match the context path carefully
In Tomcat, the context path determines where the application is reached. Make sure the subdomain and application path match your expected URL structure. For example, you may want app.example.com to open the app directly, without an extra path like /myapp unless it is required.
Check file permissions and ownership
Java applications often fail when deployment files or directories have incorrect permissions. If your subdomain points to a deployment folder, confirm that the service account can read and write the necessary files.
Review logs after changes
After deploying a new version or changing the Java configuration, review Tomcat and web server logs. This helps you catch startup warnings, connector issues, and missing resource errors early.
Choose a clear naming scheme
Use names that describe the purpose of the subdomain. For example:
- app.example.com
- api.example.com
- admin.example.com
- staging.example.com
This keeps the hosting account easier to understand, especially when several people manage the same Plesk subscription.
Common issues with subdomains and Tomcat in Plesk
Even when the configuration is correct, a few common problems can affect how a subdomain behaves with Tomcat hosting.
The subdomain opens the default site instead of the Java app
This usually means the subdomain is not connected to the Tomcat application correctly, or the routing points to a plain web directory rather than the deployed app. Check the My App Server settings and confirm the deployment target.
DNS changes are not visible yet
If you just created the subdomain, DNS propagation may still be in progress. It can take some time before the new record is visible everywhere.
The app works on the server but not in the browser
This may indicate a connector, proxy, or application path problem. Review Tomcat startup logs and make sure the subdomain is sending traffic to the correct service.
Files uploaded to the wrong directory
If your WAR file or application resources are placed in the main domain directory instead of the subdomain’s directory, the app may not load correctly. Always verify the document root before deploying.
Port or service conflicts
Because a Tomcat instance must run cleanly inside your hosting account, conflicting service settings can prevent the app from starting. If you manage a private JVM, check that the service is running and that the selected Java version is compatible with the application.
When to use a subdomain instead of a subfolder
For Java hosting in Plesk, a subdomain is often a better choice than a subfolder when the application is separate from the main site. A subfolder such as example.com/app can work in some cases, but a subdomain usually gives you cleaner separation and easier control over hosting settings.
Use a subdomain when:
- the Java app has its own deployment lifecycle
- you want separate testing and production environments
- the app needs its own Tomcat or JVM configuration
- you want clearer administration in Plesk
Use a subfolder only when the app is tightly integrated with the main website and the hosting layout is intentionally shared.
How subdomains help with Java application management
Subdomains make Java hosting more manageable because they give each application a distinct entry point. This is especially helpful in a shared hosting environment where resources, service settings, and deployment paths need to stay organized. With My App Server, you can use this structure to run a private Tomcat instance, select a suitable Java version, and handle deployment from Plesk without needing a separate infrastructure stack.
For many small and medium applications, this provides the right balance between control and simplicity. You get a clear URL, a manageable service setup, and a practical way to host JSP or servlet-based applications alongside other hosting services.
FAQ
Can I run more than one subdomain with Tomcat hosting in Plesk?
Yes, if your hosting plan and My App Server configuration allow it. A common setup is to assign separate subdomains to separate applications or environments. The exact number depends on your hosting limits and service configuration.
Does each subdomain need its own Tomcat instance?
Not always. Some setups use one Tomcat instance with different application contexts, while others use a separate service or JVM for better isolation. The right approach depends on your hosting plan and how your Java application is deployed.
Can I use a subdomain for a WAR file deployment?
Yes. A subdomain is a common target for WAR deployments in Tomcat hosting. You can deploy the application to the subdomain’s directory or connect it through the My App Server workflow, depending on your configuration.
What should I do if the subdomain is live but the app does not start?
Check the Tomcat logs, verify the Java version, confirm the deployment path, and make sure the service is running. Also check permissions and any application-specific configuration files.
Can I change the Java version for one subdomain only?
In a setup with a private JVM or separate app server configuration, that may be possible. This is one of the practical benefits of managed Java hosting through My App Server. Availability depends on the hosting plan and the versions installed in your account.
Is a subdomain better for staging and testing?
Yes. A staging subdomain is usually the safest way to test changes before making them available on the live site. It keeps testing separate from the production domain and simplifies troubleshooting.
Summary
Subdomains are a practical way to organize Tomcat hosting in Plesk. They let you separate Java applications, connect each app to the right deployment path, and manage services in a structured way. In an ITA hosting environment with My App Server, you can use subdomains to run Apache Tomcat or a private JVM, deploy WAR-based applications, and manage Java hosting from Plesk with clear control over versions and service settings.
For most JSP, servlet, and small to medium Java projects, the subdomain approach offers the best balance of simplicity, isolation, and day-to-day manageability. If you keep the DNS, document root, Tomcat deployment, and logs in sync, your subdomain-based hosting setup will be much easier to maintain and scale within the limits of your hosting plan.