If you want your Tomcat application to open on a domain such as example.com or app.example.com, you need to connect the domain at DNS level and then make sure the web server or application layer points to the correct Tomcat service. In a managed hosting environment with Plesk and My App Server, this is usually straightforward: the domain resolves to the hosting account, Apache receives the request, and Tomcat serves the application through the configured connector or reverse proxy path.
The exact steps depend on whether you want the application to open on the root domain, a subdomain, or only on a specific path. In most cases, the safest and cleanest setup is to use a subdomain for the Java application, such as app.example.com, and map it to the Tomcat app server running inside your hosting account. If you need the application on the main domain, you can still do it, but you should plan the site structure carefully to avoid conflicts with other web content.
What needs to be in place before you connect the domain
Before changing DNS or hosting settings, make sure the application is already deployed and working inside My App Server. A domain connection does not install or repair the Tomcat app itself; it only makes the application reachable by a public URL.
- The domain is added to your hosting account or can be pointed to it with DNS.
- Your Tomcat application is installed and running in My App Server.
- You know which URL or port the app currently uses internally.
- You have access to Plesk or the hosting control panel.
- You have an SSL certificate ready if you want HTTPS.
If your app is a WAR-based application, confirm that it starts correctly and returns a page when accessed through the internal Tomcat service. If the app is not running locally inside the hosting environment, domain mapping will not help until the service is healthy.
Choose the connection method
There are three common ways to connect a domain to a Tomcat application:
1. Domain or subdomain points to the hosting account
This is the most common setup in managed hosting. You point the domain’s DNS records to the hosting server, then configure Apache or the control panel to route the domain to the Tomcat-backed application. This method is ideal when the website is hosted in the same account as the Java application.
2. Subdomain is assigned to the application
This is usually the simplest option for Java hosting. For example, app.example.com can be dedicated to Tomcat, while www.example.com remains a static site, CMS, or landing page. It keeps the configuration clear and reduces the risk of path conflicts.
3. Public path is forwarded to Tomcat
In some cases, you may want the app to live under a path such as example.com/myapp. This is possible, but it is more sensitive to Apache and application routing rules. For JSP and servlet apps, path-based mapping often requires extra care with context roots, redirects, and absolute links.
Recommended setup for Tomcat hosting
For most small and medium Java applications, the recommended pattern is:
- Use a dedicated subdomain for the Tomcat app.
- Keep DNS simple with an A record or CNAME record.
- Use the My App Server service in Plesk to manage the Tomcat instance.
- Enable SSL so the application opens over HTTPS.
- Use one application per domain or subdomain whenever possible.
This approach works well for Java hosting, JSP hosting, servlet hosting, and private JVM hosting because it avoids collisions with other web applications or file-based content served by Apache.
Step 1: Point the domain to your hosting account
Start by adjusting DNS at your domain registrar or DNS provider. The goal is to make the domain resolve to the hosting platform where your Tomcat application is running.
For a root domain
If you want example.com to open the application, set the domain’s A record to the IP address of your hosting account. If you use IPv6, you may also need an AAAA record.
For a subdomain
If you want app.example.com, create either:
- a CNAME record pointing to the main domain or hosting hostname, or
- an A record pointing directly to the server IP.
A subdomain is often easier to manage for Tomcat apps because it can be dedicated to the application without affecting the main site.
Wait for DNS propagation
After saving DNS changes, allow time for propagation. Depending on TTL values and cache, the new routing may take from a few minutes to several hours to become visible everywhere.
Step 2: Add the domain in Plesk if needed
If the domain is not already available in your hosting account, add it in Plesk first. The hosting platform needs to know that the domain belongs to your subscription and can be used for web routing.
Once the domain is added, check whether it is configured as a main domain, alias, or subdomain. The right type depends on your setup:
- Main domain if the application should be served from the primary website address.
- Domain alias if you want an alternate hostname to reach the same app.
- Subdomain if you want a separate URL for the Tomcat service.
If you are using My App Server, the domain should be aligned with the app’s public URL so the control panel and Apache routing rules match the intended address.
Step 3: Create or select the Tomcat application in My App Server
My App Server provides a convenient way to install and control a private JVM and Tomcat instance inside your hosting account. Depending on the available versions, you can install a ready-made Java/Tomcat combination with a button or upload and configure a custom version manually.
In the app server configuration, confirm the following:
- The correct Java version is selected.
- The Tomcat service is running.
- The application deployment path is correct.
- The public URL or connector target matches the domain you want to use.
If the app already runs on an internal port or service endpoint, note that port because it may be used in the proxy or connector configuration behind Apache.
Step 4: Map the domain to the application
How this is done depends on the hosting account configuration. In a Plesk-based Java hosting environment, the domain usually needs to be linked to the Tomcat application service through the hosting control panel or the My App Server extension.
If the application should open at the root of the domain
Set the domain so requests to example.com are forwarded to the Tomcat application. In many setups, Apache handles the public request and forwards it internally to Tomcat. This can be done through a proxy, connector, or predefined application binding in the panel.
Make sure the app’s context path is compatible with the root domain. If Tomcat deploys the app as a non-root context, you may need to adjust the deployment name or use a proxy rule so the public URL stays clean.
If the application should open on a subdomain
Assign the subdomain to the application in the hosting panel and connect it to the Tomcat service. This is usually the easiest way to publish a Java app without affecting the primary website.
Example:
- Public URL: https://app.example.com
- Internal service: Tomcat running under My App Server
- Routing: Apache or panel-managed reverse proxy to the Java app
If the application should open under a path
Path-based URLs such as example.com/app can work, but they require extra attention. Your application must generate links, redirects, and static resource paths correctly. In Tomcat, the context path and the public path should be aligned to prevent broken assets or redirect loops.
For path-based setups, test at least:
- login and logout redirects
- static CSS and JavaScript files
- form submissions
- absolute and relative links
- file downloads and API endpoints
Step 5: Configure Apache routing if required
In a managed hosting environment, Apache often sits in front of Tomcat and handles the public request first. That means the domain can be resolved by Apache, while Tomcat serves the dynamic Java content behind it.
If the hosting platform uses a proxy or connector model, check whether the domain needs a specific Apache rule. The exact implementation may differ, but the goal is the same: requests for the domain should reach the correct application without exposing unnecessary internal ports.
Common points to verify:
- The domain points to the correct document root or proxy target.
- No existing site configuration conflicts with the new Java app.
- The app server path is not blocked by another virtual host rule.
- Forwarding headers preserve the original host name and HTTPS scheme.
If you already host a static website on the same account, avoid overwriting its Apache configuration unless you intentionally want Tomcat to replace it.
Step 6: Enable SSL for the domain
Once the domain resolves correctly, install or assign an SSL certificate. For Java hosting, HTTPS is strongly recommended because most modern applications depend on secure cookies, secure logins, and browser trust.
After the certificate is installed, confirm that:
- https:// opens the same app as http://
- the browser shows a valid certificate for the domain
- redirects from HTTP to HTTPS work correctly
- the application generates secure links and callbacks
If the app sits behind Apache, make sure Tomcat is aware that the public request is HTTPS. Otherwise, the application may create incorrect redirects or mark cookies as insecure. This is especially important for login pages, session handling, and external callback URLs.
Step 7: Test the public URL
After DNS, routing, and SSL are in place, test the public URL from a browser and from a basic HTTP request. Check that the page loads, the correct app responds, and the response headers look as expected.
Test the following:
- domain opens the intended Tomcat application
- HTTPS works without certificate warnings
- www and non-www behaviour is consistent if both are used
- internal app redirects do not break the public domain
- static files load correctly
- the app does not expose internal service ports
If the page does not load, inspect the Plesk service status and the application logs. In many cases, a connection problem is caused by one of the following: the app is stopped, the domain is not pointed to the server, the proxy target is wrong, or SSL is not fully configured.
Common connection scenarios
Domain replacement after moving an app
If you migrated a Java app from one temporary URL to a real domain, update any hardcoded URLs, callback addresses, and configuration files. Tomcat itself may start correctly, but the application can still reference the old address in emails, redirects, or API integrations.
Multiple domains for the same app
You can point more than one domain to the same application, but decide which address is the canonical one. Then configure redirects so visitors and search engines consistently land on the preferred URL.
Separate website and Java app
Many hosting customers keep the main website on one domain and use a Java app on another subdomain. This is often the best choice if the site content is not Java-based and the application has its own login, dashboard, or API endpoints.
Custom Tomcat version
If you uploaded a custom Tomcat version or a different Java runtime, double-check compatibility with the deployed application. A domain connection will not fix startup errors caused by unsupported Java versions, missing libraries, or wrong context settings.
Troubleshooting checklist
If the domain does not reach your Tomcat app, work through this checklist in order:
- Confirm the DNS record points to the correct hosting IP.
- Wait long enough for DNS propagation.
- Check that the domain is added in the hosting control panel.
- Verify that My App Server shows the Tomcat service as running.
- Make sure the app is deployed and starts without errors.
- Confirm that Apache or proxy routing points to the app.
- Check whether the SSL certificate is valid for the exact domain name.
- Review application and service logs for startup or routing errors.
If you see the wrong page, the most common cause is a domain conflict. Another site or virtual host may already be using the same hostname. If you see a blank page or server error, the app may be running but not mapped correctly to the public URL.
Best practices for Tomcat domain mapping
- Use one public hostname per app whenever possible.
- Prefer a subdomain for Java applications with their own interface.
- Keep DNS changes minimal and documented.
- Use HTTPS from the beginning, not after launch.
- Match the application context path with the public URL.
- Avoid hardcoding internal ports in public links.
- Test redirects, login flows, and static assets after every change.
These practices help keep the setup stable in a shared hosting environment where Apache, Plesk, and a private Tomcat service all play a role in the final public URL.
FAQ
Can I connect a domain directly to a Tomcat app?
Yes. In a managed hosting setup, the domain usually points to the hosting account first, and then Apache or the control panel routes traffic to Tomcat. Direct access to the Tomcat port is usually not the preferred public setup.
Should I use a root domain or a subdomain?
A subdomain is usually easier and cleaner for Tomcat hosting. A root domain can work, but it may require more careful web server and application configuration.
Do I need to change Tomcat settings when I add a domain?
Sometimes yes. If the app was built for a different context path or internal URL, you may need to adjust redirects, public URL settings, or connector configuration so the application behaves correctly on the new domain.
Can I use HTTPS with My App Server?
Yes. Install an SSL certificate for the domain and confirm that the public URL opens over HTTPS. This is recommended for all Java applications exposed on the internet.
What if I want the app under /app instead of a subdomain?
That is possible, but it is more sensitive to configuration. Make sure Tomcat’s context path and the public path are aligned, and test all links and redirects carefully.
Why does the domain open the wrong site?
Usually the DNS record or virtual host is pointing elsewhere, or another domain configuration is taking priority. Check the domain assignment in Plesk and the Apache routing rules.
Conclusion
Connecting a domain to a Tomcat application is mainly a combination of DNS, hosting panel configuration, and correct application routing. In a Plesk-based Java hosting environment with My App Server, the process is usually manageable: point the domain to the hosting account, assign it in the control panel, connect it to the running Tomcat service, and secure it with SSL.
For most applications, the best result comes from using a dedicated subdomain and keeping the mapping simple. That makes the public URL easier to maintain, reduces conflicts with other site content, and gives you a cleaner setup for JSP, servlet, and WAR deployments.
If the domain is connected but the app still does not load, focus on the service status, routing, and SSL settings. In most cases, the issue is not the domain itself, but a mismatch between the public hostname and the Tomcat application configuration.