For a Java app hosted in Plesk, the settings that matter most are the ones that control how the domain resolves, how requests reach Tomcat, where your application files live, and how much access the app has to resources. If you are running a WAR, JSP, or servlet application on a managed hosting account with a private JVM or Apache Tomcat through My App Server, the best results usually come from keeping the domain setup simple, predictable, and aligned with the way Java apps are deployed.
In practice, the most important choices are not only the Java version or Tomcat version. They also include the domain name, document root, proxy and web server handling, SSL, DNS, and whether the hosting settings match the app’s URL structure and startup requirements. Small changes in Plesk can affect login flows, static assets, redirects, session handling, and deployment paths.
Which hosting settings matter most for a Java app?
When hosting a Java application in Plesk, focus on the settings that affect routing, runtime, and file access first. These are the areas that usually have the biggest impact on whether the app works reliably:
- Domain and subdomain setup — determines the URL used by the app and whether requests are sent to the correct virtual host.
- Document root — controls where files are served from and where your deployment assets are placed.
- SSL/TLS settings — important for secure logins, callbacks, and browser trust.
- Hosting type and web server mode — affects how Apache, Plesk, and Tomcat work together.
- Java/Tomcat version — must match the app’s framework, build target, and dependencies.
- Resource limits — CPU, memory, and process limits can affect startup and stability.
- File permissions and ownership — critical for deployment, logs, uploads, and runtime access.
- DNS and hostname records — needed so users reach the app correctly.
For UK-based projects, the goal is usually to keep the setup straightforward for users, search engines, and third-party services while ensuring the app behaves consistently across browsers and secure connections.
Domain name and subdomain setup
The domain is the first setting to check because it defines the public address of the application. A Java app may run on a root domain, such as example.co.uk, or on a subdomain, such as app.example.co.uk. In Plesk, this choice affects DNS, site configuration, SSL certificates, and deployment paths.
When to use a root domain
Use the root domain when the Java app is the main site and there is no separate PHP, HTML, or CMS website on the same host. This can simplify redirects and certificate management. However, it also means all traffic for the domain is handled by the Java app, so the setup must be consistent.
When to use a subdomain
A subdomain is often the cleaner option for Java hosting because it keeps the application separate from other services. This is useful when you want:
- a dedicated app URL;
- clear separation from marketing pages or static content;
- easier testing and staging;
- different routing or deployment rules.
For example, many teams use app.domain.co.uk for the Java app and keep www.domain.co.uk for the main site.
What to check in Plesk
- Confirm that the domain or subdomain points to the correct hosting subscription.
- Make sure the DNS zone contains the right A or CNAME record.
- Check that the domain alias or redirect rules do not create loops.
- Verify that the chosen hostname matches the SSL certificate.
Document root and application path
The document root is one of the most common settings that affects Java app deployment. Even when Tomcat serves the application, the domain still needs a clear path for web content, static files, and related assets. A wrong document root can cause missing images, broken CSS, or incorrect index handling.
Why the document root matters
In a managed Plesk environment, the document root helps define where the web server expects site files. For Java hosting, this matters when:
- serving static resources alongside a servlet or JSP app;
- mapping a domain to a Tomcat web application;
- using a reverse proxy or forwarding setup;
- deploying multiple app components under one subscription.
Practical guidance
- Keep the document root aligned with the app’s intended public files.
- Do not place application code in the wrong web root by accident.
- Separate uploaded files from compiled application packages if possible.
- Use clear directory names so deployment and troubleshooting are easier.
If you use My App Server with a private JVM or Tomcat instance, the application path should match how the service expects WAR deployment, unpacked directories, or custom server mappings.
Java version and Tomcat version
The Java version is one of the most important technical settings around any Java app. A build compiled for a newer runtime may fail on an older JVM, while some older libraries may not run correctly on a newer release without adjustments. The same applies to Tomcat versions, especially when servlet APIs, JSP compilation, or session behavior are involved.
Why version choice matters
Version mismatch can lead to:
- startup errors;
- class loading problems;
- unsupported library methods;
- framework incompatibility;
- deployment failures after upgrades.
What to verify before deploying
- Check which Java version the app was built and tested against.
- Confirm whether the app requires a specific Tomcat branch.
- Review framework documentation for runtime support.
- Test the app after switching versions in Plesk.
With My App Server, you can install a ready-made Java/Tomcat version with a button or upload and configure another version manually when needed. That is especially useful for small and medium Java apps that need a private JVM without the complexity of a large application platform.
Apache, reverse proxy, and request handling
In a Plesk hosting setup, Apache often sits in front of Tomcat or works alongside it. This matters because the web server controls how requests are forwarded, how static assets are served, and how HTTPS traffic is handled before the application receives it.
Settings that can affect a Java app
- proxy mode enabled or disabled;
- default web server behavior for the domain;
- rewrite rules in the site configuration;
- headers passed to Tomcat;
- path-based routing for static and dynamic resources.
If your Java app depends on absolute URLs, authentication redirects, or callback endpoints, proxy and request forwarding settings become especially important. Misconfigured forwarding can cause login loops, wrong redirect targets, or mixed-content warnings.
Useful checks
- Confirm that the app sees the correct scheme, host, and port.
- Check whether forwarded HTTPS headers are preserved.
- Make sure rewrite rules do not block servlet paths.
- Test clean URLs and direct servlet URLs separately.
SSL/TLS and certificate configuration
For a Java application, SSL is not just a browser requirement. It often affects authentication, payment flows, API integration, and session security. In the UK market, users also expect secure access by default, especially on login pages and account portals.
Why SSL is important for Java apps
- protects credentials and form submissions;
- avoids browser warnings;
- supports secure redirects and callbacks;
- helps external services trust your endpoint.
What to check in Plesk
- Install a certificate for the exact domain or subdomain in use.
- Enable HTTPS for the site and verify the redirect from HTTP.
- Check that mixed content is not loading over plain HTTP.
- Make sure Tomcat or the proxy is aware of secure requests.
If SSL is enabled but the app still thinks it is running over HTTP, login redirects and generated links may be wrong. In that case, review the proxy and forwarded header settings together with the domain configuration.
DNS records and hostname resolution
DNS is often overlooked, but it is one of the settings that most directly determines whether users can reach the app. A correctly configured Java app can still appear broken if the domain points to the wrong address or the DNS record has not propagated.
What matters most
- the A record for the root domain;
- the A or CNAME record for subdomains;
- mail-related records if the app sends email notifications;
- TTL values when you are testing changes.
Common problems
- domain resolves to an old server or old IP;
- www and non-www point to different places;
- subdomain does not exist in the DNS zone;
- certificate mismatch caused by a hostname typo.
If you are switching a Java app to a new hosting setup, update DNS only after the new hosting subscription is ready. Then test both the root domain and any subdomains used by the app.
Resource limits and app stability
Java apps can be more resource-sensitive than simple static websites. Even small applications may need enough memory to start the JVM, compile JSP files, and handle sessions. In shared hosting or managed hosting, resource limits are especially important because they affect startup speed and runtime stability.
Resources to review
- memory available to the private JVM;
- process or service limits;
- disk usage for logs and uploads;
- CPU usage under concurrent requests;
- inode or file count limits where applicable.
How this affects hosting settings
If the app starts but stops under load, the issue may not be the code. It may be the hosting settings around memory, service control, or runtime limits. Log files can also grow quickly, especially with debug output or repeated stack traces.
For best results, keep an eye on application logs after deployment and confirm the service can restart cleanly after changes to Java or Tomcat versions.
File permissions and ownership
File permissions are a practical but critical part of Java hosting in Plesk. If Tomcat cannot read a WAR file, write a temporary file, or access a log directory, the application may fail even when the domain and DNS are correct.
Files and folders to review
- WAR deployment directory;
- unpacked application folder;
- logs directory;
- temporary files and cache folders;
- upload paths used by the app.
Best practice
- Use consistent ownership for app files.
- Avoid manual permission changes unless needed.
- Keep writable folders separate from code folders.
- Verify that the service user can read configuration files.
When using My App Server, this becomes even more important because the app runs with its own JVM and service control rules. A deployment that works in one directory may fail in another if ownership or access rights are inconsistent.
How to review the most important settings in Plesk
If you are troubleshooting a Java app, the quickest approach is to check the hosting settings in a fixed order. This helps you avoid changing multiple things at once and makes it easier to find the real cause of the problem.
Recommended checklist
- Confirm the domain or subdomain is correct.
- Check DNS resolution and hostname matching.
- Review the document root and deployment path.
- Verify the SSL certificate and HTTP to HTTPS redirect.
- Confirm the Java and Tomcat versions match the app requirements.
- Check Apache or proxy handling for request forwarding.
- Review file permissions for app, logs, and uploads.
- Look at resource usage and service status after deployment.
When to use My App Server settings
Use the My App Server controls when you need to:
- start or stop the private Java service;
- change the installed Java or Tomcat version;
- deploy or replace a WAR package;
- review service output and runtime behavior;
- adjust a custom app server setup for a specific project.
This is especially useful when the app is small to medium in size and you want direct control in Plesk without managing a complex external platform.
Troubleshooting common hosting setting issues
The app loads, but static files are missing
Check the document root, file paths, and whether Apache is serving the correct directory. Also verify that CSS, JavaScript, and image files are deployed where the app expects them.
The app redirects in a loop
This often points to SSL, proxy, or hostname settings. Verify the correct domain, HTTPS redirect, and forwarded protocol headers.
The WAR deploys, but the service does not start
Review Java version compatibility, Tomcat version compatibility, and permission issues in the deployment or log directories.
Login sessions keep dropping
Look at cookie settings, secure flag behavior, proxy configuration, and whether the app is being accessed through both HTTP and HTTPS.
Changes in Plesk do not seem to apply
Check whether the service was restarted after the change, whether the DNS record has propagated, and whether the browser is caching an old redirect or certificate.
FAQ
Do I need a separate domain for every Java app?
No. You can run multiple apps under different subdomains or paths, depending on how your hosting subscription and Tomcat setup are structured. For clarity and easier management, many teams prefer one app per subdomain.
Is the Java version more important than the Tomcat version?
Both matter. The Java runtime must support the app’s code and libraries, while Tomcat must support the servlet and JSP features the app uses. A mismatch in either can break the deployment.
Can I host a JSP or servlet app without a full enterprise stack?
Yes. A private JVM and Apache Tomcat are often enough for JSP, servlet, and smaller Java applications. This setup is practical when you want control through Plesk without complex infrastructure.
Why does SSL affect my Java app if the app itself is working?
Because many apps generate absolute links, redirect users after login, or communicate with third-party services. If SSL or forwarded headers are misconfigured, the app may work partially but still behave incorrectly in secure flows.
What should I check first if my Java app fails after a hosting change?
Start with the domain, DNS, Java version, Tomcat version, and file permissions. These are the settings most likely to cause immediate failures after migration or reconfiguration.
Does My App Server support manual custom app server setups?
Yes, in the hosting context described here you can work with ready-made Java/Tomcat versions or upload and configure another version manually, depending on the app’s needs and the account’s limits.
Conclusion
For a Java app in Plesk, the most important hosting settings are the ones that control the domain, document root, SSL, DNS, Java/Tomcat version, request handling, file access, and resource limits. If these are correct, a WAR, JSP, or servlet application is much more likely to deploy cleanly and run with fewer issues.
In a managed hosting setup with My App Server, the main advantage is practical control: you can manage a private JVM, choose a suitable Java/Tomcat version, start or stop the service, and keep the app isolated within the hosting account. For small and medium Java hosting projects, that usually provides the right balance between control and simplicity.