How to connect a domain to a Java application

To connect a domain to a Java application, you usually need two things to work together: the domain must resolve to your hosting account, and your web server must route incoming traffic to the Java app or Tomcat instance. In a managed hosting environment with Plesk and a Java extension such as My App Server, this is typically done by assigning the domain in the control panel, configuring DNS, and making sure the application listens on the correct internal path or service.

If you are hosting a WAR, JSP, servlet, or other Java web application on a shared hosting account, the most practical setup is to use a domain or subdomain as the public address and connect it to the Java service through the panel. This gives you a clean public URL like example.com or app.example.com while your Java application runs on its own private JVM or Tomcat instance.

What “connecting a domain” means for a Java application

When people ask how to connect a domain to a Java application, they usually mean one of these tasks:

  • Point a domain to the hosting account where the Java app is deployed.
  • Map a domain or subdomain to a Java/Tomcat application in Plesk.
  • Make the domain open the application instead of a default placeholder page.
  • Use HTTPS so the Java app is available securely on the chosen hostname.

In a Java hosting setup, the domain itself does not “run” the application. Instead, DNS sends visitors to your hosting server, Apache or the proxy layer receives the request, and the hosting platform forwards it to the Java service. In an environment with My App Server, this forwarding is handled through the control panel and the application configuration.

Before you start: what you need

Make sure you have the following ready:

  • The domain name you want to use, such as example.com or app.example.com.
  • Access to DNS management at your registrar or DNS provider.
  • Access to your hosting control panel, such as Plesk.
  • A Java application already installed or ready to deploy in My App Server.
  • The correct Java version and Tomcat version for your app, if applicable.

If the application is already installed, check which public path it expects. Some Java apps are designed to run at the domain root, while others are deployed under a context path such as /app or a subdomain.

Choose the right domain structure

Before changing DNS, decide how you want users to access the application. The most common options are:

Root domain

Use example.com if the Java app should be the main website. This is common for standalone applications, portals, and internal tools exposed publicly.

Subdomain

Use app.example.com, portal.example.com, or api.example.com if the Java app is part of a larger website or if you want to keep it separate from the main site.

Public path

Use a path such as example.com/app if your application is designed to live under an existing site. This is less common for Java hosting, but it can be useful for test environments or shared sites.

For most Java hosting scenarios, a subdomain is the cleanest option because it simplifies routing, SSL setup, and application isolation.

Step 1: Point the domain to your hosting account

The domain must resolve to the correct server before the Java application can be reached. You can do this in one of two ways:

  • Change the domain’s nameservers to the ones provided by your hosting provider.
  • Keep DNS at your current provider and update the required records manually.

If you use the hosting provider’s nameservers

This is the simplest option if you want the hosting platform to manage DNS for the domain. After the domain uses the correct nameservers, add the domain or subdomain in the panel and let the platform create or update the DNS zone.

If you manage DNS elsewhere

Set the required records at your DNS provider. In most cases, you will need:

  • An A record pointing the domain to the server IPv4 address.
  • Optionally an AAAA record if IPv6 is used.
  • A CNAME record for subdomains if you want them to follow another hostname.

Example:

  • example.com → A record to your hosting server IP
  • www.example.com → CNAME to example.com or A record to the same IP
  • app.example.com → A record to the same IP

DNS propagation may take some time depending on the TTL and the provider. In practice, this can be from a few minutes to several hours.

Step 2: Add the domain in Plesk

Once the domain resolves to your hosting account, add it in the control panel so the web server knows how to handle requests for that hostname. In Plesk, this usually means creating a domain or subdomain entry and connecting it to the correct hosting service.

For a new domain

Go to the domains section in Plesk and add the domain you want to use. Select the hosting options that match your Java setup. If the domain should open the Java application directly, make sure it is assigned to the service associated with My App Server or the relevant web stack.

For an existing domain

If the domain already exists in the panel, update its web hosting settings so it points to the Java application instead of a static site or another application type. Make sure the document root and application mapping are consistent with the Java deployment.

For a subdomain

Create the subdomain in Plesk and connect it to the Java app. This is often the easiest way to keep the app isolated from the main domain.

Examples of good subdomains for Java apps:

  • app.example.com
  • tomcat.example.com
  • api.example.com

Step 3: Deploy or select the Java application

In an ITA Java hosting environment, My App Server lets you install and manage a private JVM or Apache Tomcat instance from the control panel. Once the domain is in place, connect it to the application that should answer requests for that hostname.

If you are using a ready-made Tomcat version

Select the Java/Tomcat version that fits your application. Some apps require a specific Java release or servlet container version, so it is important to match the runtime to the app requirements.

If you are using a custom Java server

You can upload and configure a custom app server version when supported by the platform. In that case, make sure the service is running and that the domain is mapped to the correct port or internal application entry point.

If you are deploying a WAR file

Upload the WAR package through the control panel or deployment tool provided by the Java hosting service. After deployment, confirm the application context path. If the app is deployed as /myapp, then the public URL may be example.com/myapp unless you configure the domain to point directly to it.

Step 4: Map the domain to the application

The exact mapping method depends on how your hosting platform exposes Java applications. In a managed Plesk-based setup, this usually means choosing the Java service and associating it with the domain or subdomain.

Typical mapping models include:

  • Domain root mapping — the domain opens the Java app directly.
  • Virtual host mapping — Apache or a proxy layer forwards the hostname to Tomcat.
  • Context path mapping — the domain points to a specific application path inside Tomcat.

For example:

  • example.com → Java app root
  • app.example.com → Tomcat application
  • example.com/app → application context path

If your app still shows a default page, check whether the domain is mapped to the correct service and whether the application is listening on the expected internal endpoint.

Step 5: Set up Apache and proxy routing if needed

In many Java hosting setups, Apache handles the public hostname while the Java application runs separately in Tomcat or another JVM. Apache then forwards dynamic requests to the Java service.

This is useful because it lets you combine:

  • normal web hosting features, such as static files and HTTPS,
  • with Java application handling through Tomcat or a private JVM.

If your platform uses Apache in front of Tomcat, make sure:

  • the domain is assigned to the correct hosting subscription,
  • proxy or connector settings are enabled if required,
  • the Java service is running,
  • the application does not conflict with another site on the same account.

In a shared hosting environment, this setup is practical for small and medium Java applications, including JSP sites, servlet apps, and lightweight business tools.

Step 6: Connect HTTPS to the domain

For a public Java application, HTTPS should be enabled on the domain as soon as possible. This is important for login pages, forms, APIs, and browser trust.

In most control panel setups, you can activate a certificate for the domain or subdomain after DNS is pointed correctly. Once the certificate is issued, verify that:

  • the domain opens on https://,
  • there are no mixed-content errors,
  • the Java app correctly generates secure URLs if needed.

If the application builds absolute links internally, check its base URL or server configuration so it uses the HTTPS hostname and not a local Tomcat address.

Step 7: Test the connection

After you have added the domain and connected it to the Java app, test it carefully.

What to verify

  • The domain resolves to the correct server IP.
  • The page opens without a 404 or default hosting page.
  • The Java application starts normally.
  • Static files, forms, and login pages work as expected.
  • HTTPS loads without certificate warnings.

Useful checks

  • Open the domain in a private browser window.
  • Test both the root domain and www if both should work.
  • Check whether the app responds correctly on the exact hostname you configured.
  • Review the application logs if the site does not load.

Common problems and how to fix them

The domain still shows a placeholder page

This usually means the domain is not mapped to the Java application yet, or the web root still points to the default site. Check the domain settings in Plesk and confirm that the Java service is selected.

The browser shows a 404 error

The application may be deployed under a different context path than the one you are using. Confirm whether the app is available at the root domain or under a specific path such as /app.

The domain opens, but the Java app does not start

Check whether the Tomcat service or private JVM is running. Also verify that the selected Java version is compatible with the application.

HTTPS does not work

The certificate may not have been issued yet, or DNS may still be propagating. Make sure the domain points to the right server before issuing SSL.

www and non-www behave differently

If you want both versions to work, configure DNS and web hosting settings for both hostnames. You may also want to set a preferred version and redirect the other one to avoid duplicate content.

Best practices for Java hosting domains

To keep your setup stable and easy to maintain, follow these recommendations:

  • Use a subdomain for the Java app when it should be separate from the main website.
  • Keep DNS simple: use one A record per hostname unless you have a specific reason to do otherwise.
  • Match the Java version to the application requirements before deployment.
  • Use HTTPS from the start.
  • Check logs after every domain or deployment change.
  • Prefer one application per hostname when possible.

If you are hosting more than one app on the same account, separate them by hostname or subdomain so each Java service remains easy to manage in Plesk.

Example: connect app.example.com to a Tomcat application

Here is a simple example of a typical setup:

  • Create app.example.com in DNS with an A record to the hosting server IP.
  • Add the subdomain in Plesk.
  • Enable the Java service through My App Server.
  • Select the appropriate Tomcat and Java versions.
  • Deploy the WAR file or select the application package.
  • Assign the hostname to the Java application.
  • Issue an SSL certificate for app.example.com.
  • Test the URL in a browser.

After these steps, visitors should reach the Java application directly through the subdomain.

FAQ

Can I connect a domain to a Java application without a subdomain?

Yes. You can connect the root domain if you want the Java app to be the main site. This is common for standalone applications. If you also need a separate website, a subdomain is often easier to manage.

Do I need Tomcat to connect a domain to a Java app?

Not always, but Tomcat is a common option for JSP, servlet, and WAR-based applications. In a managed Java hosting setup, Tomcat or a similar servlet container is typically the practical choice.

How long does DNS take to work?

It depends on your DNS provider and TTL settings. Changes may appear within minutes, but full propagation can take longer.

Why does my Java app work on one URL but not another?

That usually means the domain mapping, DNS record, or application context path is different between the two URLs. Check both the Plesk domain assignment and the Tomcat application path.

Can I use both example.com and www.example.com?

Yes, but you should configure both hostnames consistently. Many site owners choose one as the primary address and redirect the other to it.

Can I point several domains to the same Java application?

Yes, if the hosting setup allows it. This is often used for aliases, brand domains, or redirect domains. Make sure the SSL certificate covers every hostname you want to serve.

What if my app needs a custom Java version?

Use the Java version that matches the application requirements. If the exact version is not available in the default list, custom app server support may be needed, depending on the hosting platform.

Conclusion

Connecting a domain to a Java application is mainly a matter of DNS, domain assignment in the control panel, and correct mapping to the Java service. In a Plesk-based Java hosting environment with My App Server, the process is usually straightforward: point the domain to the server, add it in the panel, connect it to the Tomcat or private JVM instance, enable HTTPS, and test the final URL.

For most Java hosting, Tomcat hosting, JSP hosting, and servlet hosting use cases, a subdomain mapped to a managed Java service is the cleanest and most reliable setup. If the application is small to medium in size and runs on a shared hosting account, this approach gives you a practical balance of control, flexibility, and ease of use.

  • 0 Users Found This Useful
Was this answer helpful?