To connect a domain to a Tomcat application, you usually need three things to line up correctly: the domain’s DNS, the web server or proxy that receives traffic on port 80/443, and the Tomcat application itself. In a managed hosting environment with Plesk and a Java hosting extension such as My App Server, this is typically done by pointing the domain to the hosting account, then assigning the public URL or path to the Tomcat service or WAR application.
If you want visitors to reach your Tomcat app at a clean address such as https://example.co.uk or https://example.co.uk/app, the domain must resolve to the hosting platform and the hosting platform must know where to send the request internally. The exact setup depends on whether you want the app on the root domain, on a subdomain, or under a subdirectory.
What you need before connecting the domain
Before changing DNS or control panel settings, make sure the Tomcat application is already installed and running in your hosting account. In a typical Plesk-based Java hosting setup, this means the app server service is available, the JVM is selected, and the application can start locally before you map the public domain to it.
- A registered domain name, for example example.co.uk
- Access to the domain’s DNS provider or registrar
- A hosting account with Plesk access
- My App Server, Apache Tomcat, or another Java application service enabled
- An installed application, usually a WAR file, servlet app, or JSP-based app
- SSL certificate if you plan to use HTTPS, which is strongly recommended
If you are using a shared hosting account with private JVM hosting, the domain usually does not point directly to Tomcat. Instead, the domain resolves to the hosting platform, and Apache or a proxy layer forwards the request to the Tomcat application. This is the normal and recommended setup for small and medium Java applications in managed hosting.
Choose the right mapping type: root domain, subdomain, or subdirectory
The first decision is where the application should appear publicly. This affects DNS, Apache, and Tomcat configuration.
1. Root domain
This is the cleanest option if the application should be reachable at the main site address, such as example.co.uk. It is common for a single Java application or a main public site.
2. Subdomain
A subdomain such as app.example.co.uk or tomcat.example.co.uk is often easier to manage because it keeps the application separate from other services. This is a good choice if you already have a website on the root domain and want the Tomcat app on its own hostname.
3. Subdirectory
A path such as example.co.uk/app can work, but it is usually more complex for Tomcat applications because the app must be written or configured correctly for a context path. If you are using a simple JSP or servlet application, a subdomain is often easier and more reliable.
Step 1: Point the domain to your hosting account
Start by updating DNS so the domain resolves to the hosting platform. The domain must be able to reach the web server that will accept the request before Tomcat can serve the application.
In most cases you will either:
- Change the nameservers to the hosting provider’s nameservers, or
- Keep DNS at your registrar and update the A record or AAAA record
If you are only connecting one hostname, changing the A record is often the simplest approach. For example:
- example.co.uk → A record to the hosting IP
- www.example.co.uk → CNAME to example.co.uk, or a separate A record
- app.example.co.uk → A record to the hosting IP
DNS changes can take time to propagate. In practice, this may be quick, but you should allow for full propagation before testing or making further changes.
Step 2: Add the domain in Plesk
After DNS is in place, add the domain or subdomain in the control panel so the hosting platform recognizes it. In Plesk, this usually means creating a domain or subdomain entry and assigning it to the correct hosting subscription.
For a root domain, create the domain entry normally. For a subdomain, create the subdomain under the parent domain or as a separate domain if your plan allows it. Make sure the document root and hosting settings match your intended setup.
At this stage, the web server should be able to accept requests for the hostname, even if the Tomcat application is not yet connected.
Step 3: Install or verify the Tomcat application
In an ITA Java hosting environment, My App Server lets you install and manage your own Apache Tomcat or private JVM inside the hosting account. You may have a set of ready-made Java and Tomcat versions available for one-click installation, while other versions can be uploaded and configured manually.
Before you connect the domain, confirm the following:
- The Tomcat service is running
- The Java version matches your application requirements
- The app deploys successfully as a WAR, servlet app, or JSP site
- The application responds on its internal service URL or local port
- No startup errors appear in the service logs
If you are using a custom app server configuration, make sure the port and runtime settings are correct. A domain mapping will not fix a broken service, so testing the application locally first saves time.
Step 4: Connect the domain to the application
The way you connect the domain depends on whether the platform exposes the app through Apache, a reverse proxy, or a Tomcat context mapping. In managed hosting, the most common pattern is to route the public hostname through Apache and then forward the request to Tomcat.
Typical connection methods
- Domain as main site — the domain points to the hosting account and the app becomes the default response
- Subdomain mapped to Tomcat — the hostname is assigned to a Java app or service in Plesk
- Proxy or alias setup — Apache receives the request and passes it to the Tomcat backend
- Context path mapping — the app is published under a specific path such as /app
If you use My App Server, the service control and deployment are usually handled from the Plesk extension. That makes it easier to assign the application to the intended public URL without manual server administration. You can manage the service, select versions, and keep the Tomcat instance separate from other hosting services in the same account.
Step 5: Configure the public URL or context path
This is the key step for Tomcat hosting. The public URL must match how the app is deployed.
For a root domain
If the app should open at example.co.uk, the server must route the root hostname to the Tomcat application. Depending on the setup, this may involve making the Java app the default site or assigning the root URL to the app server service.
For a subdomain
If the app should open at app.example.co.uk, assign that hostname to the Java app in the control panel and confirm that DNS points to the same hosting account. This is often the cleanest option for Tomcat applications because the configuration stays isolated from the main website.
For a subdirectory
If the app should open at example.co.uk/app, the Tomcat application must be deployed to the correct context path. In some cases, this means renaming the WAR file or defining the application context in the server configuration. You also need to check that relative links, redirects, and session paths behave correctly under a subdirectory.
For many applications, subdirectory publishing requires extra testing. If you are unsure, a subdomain is usually simpler and more predictable.
Step 6: Enable HTTPS for the domain
Once the domain points to the app, secure it with SSL. For UK-facing websites, HTTPS is expected by users and search engines, and it also protects login forms and application data.
In Plesk, you can usually issue or install a certificate for the domain or subdomain, then enable SSL support for the site. Make sure the certificate covers the exact hostname you are using:
- example.co.uk
- www.example.co.uk
- app.example.co.uk
If the app uses both a root domain and www, include both names in the certificate or redirect one to the other consistently. After installing the certificate, test that the application loads over HTTPS and that all resources also use secure URLs.
Step 7: Check redirects, links, and application base URL
After the domain is connected, open the website in a browser and verify the full path structure. Tomcat applications often depend on a correct base URL, especially if they generate absolute links, redirects, or callback URLs.
Look for these common issues:
- Redirects still point to the old test URL
- Images, CSS, or JavaScript files load from the wrong host
- Login or session links break after switching to a new domain
- The app works on HTTP but not on HTTPS
- The app expects to run at / but is actually published under /app
If the application stores its own public URL in configuration, update it after the domain change. Many Java web apps have settings for server URL, external URL, callback URL, or base path.
Example setups
Example 1: Main domain for a Tomcat app
You want example.co.uk to serve the Tomcat application directly.
- Point example.co.uk to the hosting IP
- Add the domain in Plesk
- Install the Java app with My App Server
- Assign the domain as the public URL
- Install SSL for example.co.uk
- Test the site in HTTPS
Example 2: Subdomain for a separate application
You want app.example.co.uk to host the Java application while the root domain is used for a different website.
- Create an A record for app.example.co.uk
- Add the subdomain in Plesk
- Deploy the WAR file in My App Server
- Map the subdomain to the app
- Install a certificate for app.example.co.uk
- Verify that the app opens without mixed content warnings
Example 3: Application under a path
You want example.co.uk/app to open a Tomcat service.
- Point the domain to the hosting account
- Publish the app under the /app context
- Check that the WAR name or context mapping is correct
- Adjust internal URLs and redirects
- Enable SSL on the main domain
- Test every page and login flow
Common problems and how to fix them
The domain shows a default hosting page
This usually means DNS is correct, but the domain is not yet mapped to the Tomcat application. Check the domain settings in Plesk and verify that the public URL points to the correct service.
The browser shows a connection error
This often means DNS has not fully propagated, the record is wrong, or the hostname is not assigned to the hosting account. Confirm the A record and the Plesk domain entry.
The app works on the internal URL but not on the public domain
This usually indicates a proxy, alias, or context path mismatch. Check whether the public hostname is assigned correctly and whether the app expects a different base path.
HTTPS gives a certificate warning
The certificate may not include the exact hostname you are using. Reissue or reinstall the certificate for the correct domain or subdomain.
Static files do not load
Check for hardcoded HTTP links, missing base URL settings, or path issues caused by moving the app from one hostname to another.
The application breaks after moving from test URL to live domain
Update any environment-specific settings such as callback URLs, allowed origins, session settings, and API endpoints. Tomcat itself may be fine, but the application may still reference the old address.
Best practices for UK domain setups
For a UK domain or UK-targeted site, use a stable hostname and avoid changing it repeatedly. Search engines and users prefer a consistent public URL. If you need both www and non-www, choose one canonical version and redirect the other to it.
For most Tomcat applications in managed hosting, a subdomain is often the simplest production-style setup. It keeps the Java app separate, makes SSL easier to manage, and reduces conflicts with other websites in the same hosting account.
- Use one canonical URL
- Redirect HTTP to HTTPS
- Keep DNS records minimal and clear
- Test after every deployment
- Check logs when the site does not load as expected
How My App Server helps with domain mapping
With My App Server, the main advantage is that you can manage your Tomcat or private JVM service from the hosting control panel instead of handling everything manually at server level. This is useful for Java hosting, JSP hosting, servlet hosting, and small to medium Tomcat deployments.
You can typically:
- Install supported Java and Tomcat versions
- Upload or deploy your WAR application
- Control the service from Plesk
- Use a separate JVM for the application
- Map a domain or subdomain to the app
- Change configuration without full server administration
This setup is practical when you need a managed environment for a Java app, but do not need a heavy enterprise cluster or complex application server architecture.
FAQ
Can I point a domain directly to Tomcat?
Usually the domain points to the hosting account, and Apache or a proxy layer forwards traffic to Tomcat. In managed hosting, the public hostname is mapped to the application rather than connecting the browser directly to the Tomcat port.
Is a subdomain better than a subdirectory for Tomcat?
In many cases, yes. A subdomain is easier to configure, easier to secure with SSL, and less likely to cause path issues in Java web apps.
Do I need SSL before connecting the domain?
It is not always required to make the site resolve, but it should be enabled as soon as possible. HTTPS is the standard for live sites and avoids security warnings.
Can I use the same domain for both a website and a Tomcat app?
Yes, but you need a clear routing plan. You can use different subdomains, or publish the app under a specific path if the application supports it.
Why does my Tomcat app work on one URL but not another?
Most often the issue is a mismatch between the public URL, context path, DNS, or SSL setup. Check the hostname assigned in Plesk and the application’s own base URL settings.
What if my application needs a different Java version?
In My App Server, you can often choose from available Java and Tomcat versions or upload a custom version if needed. Make sure the selected runtime matches your app’s requirements before publishing the domain.
Conclusion
Connecting a domain to a Tomcat application is mainly about aligning DNS, hosting control panel settings, and the application’s public URL. In a Plesk-based managed hosting environment with My App Server, the process is usually straightforward: point the domain, add it in the panel, deploy the Java app, map the hostname, and enable SSL.
If you choose the right mapping style from the start, especially a subdomain or a clean root-domain setup, you will avoid most common issues with redirects, paths, and certificates. For small and medium Java applications, this gives you a practical and maintainable way to publish your Tomcat site publicly.