When a Tomcat application behaves unexpectedly, the cause is often not the app code itself but the hosting settings around it. In a Plesk-based environment, the most important items are the domain mapping, document root, service routing, Java version, Tomcat instance settings, file permissions, and the way Apache forwards requests to the application server. If you are using a managed Java hosting setup with My App Server, these settings determine whether your WAR file deploys cleanly, whether the app starts on the right port, and whether static files, JSP pages, and servlets are served correctly.
For small and medium Java hosting projects, it helps to think of Tomcat hosting as a combination of three layers: the domain settings in Plesk, the application server settings, and the runtime behavior of the JVM. A change in any one of them can affect startup, routing, memory use, logs, or the visibility of your application. This article explains which hosting settings matter most around a Tomcat app and how to check them in a practical way.
Domain and hosting settings that affect a Tomcat app
In Plesk, a domain is more than a hostname. It defines where traffic goes, which files are published, what web server handles the request, and how the hosting account is structured. For a Tomcat application, these settings are critical because the app may sit behind Apache, run on a private JVM, or be exposed through a specific document root.
Document root and deployment path
The document root tells Plesk where the website files live. For Tomcat-based sites, this setting matters because it influences:
- which directory is used for static content
- where WAR or app files may be uploaded
- how Apache resolves default pages
- whether the domain points to the Tomcat application or to a different site root
If your app is deployed into a custom folder, make sure the document root and the Tomcat deployment path are aligned. A mismatch can cause 404 errors, missing resources, or a site that opens the wrong default page.
Domain alias, subdomain, and canonical hostname
Tomcat apps are often sensitive to the hostname used in the browser. If your application generates redirects, cookies, or absolute URLs, the primary domain and any alias domains must be configured correctly. In Plesk, confirm which name is the main domain and which names are aliases or subdomains.
Useful checks include:
- the main domain points to the intended hosting subscription
- aliases resolve to the same app if needed
- subdomains have their own document roots only when you intentionally want separate apps
- redirect rules do not loop between www and non-www versions
Hosting type and web server handling
In a standard hosting panel, the web server may be Apache, nginx, or a combination of both. In a Tomcat setup, Apache often acts as the public entry point and forwards relevant requests to Tomcat. The hosting type should support this routing model cleanly.
Check whether your domain is configured to:
- serve static files directly from Apache
- pass Java application requests to Tomcat
- preserve the correct host header for application logic
- handle HTTPS termination correctly if SSL is enabled
My App Server settings that matter most
If you are using ITA’s My App Server extension in Plesk, the application server settings are often more important than the raw domain settings. My App Server is designed to let you install and manage a private Java runtime and Apache Tomcat instance from the control panel, without needing a separate complex platform. That means the exact version, service state, and deployment method all influence the behavior of your app.
Java version selection
Java version compatibility is one of the first things to verify. A Tomcat app may run on one Java release and fail on another because of unsupported language features, library dependencies, or runtime changes.
Before deployment, confirm:
- which Java version the application requires
- whether the Tomcat version supports that Java version
- if the app depends on old libraries that need a legacy runtime
- whether the app behaves differently after a Java upgrade
In managed Java hosting, it is usually safer to match the app’s required Java version first, then test before switching to a newer runtime.
Tomcat version and install method
My App Server may offer a few ready-to-install Tomcat versions, while other versions can be uploaded and configured manually. This is useful for hosting teams that need a specific servlet container version for a project, a framework, or a legacy application.
Choose the Tomcat version based on:
- application compatibility
- support for the required servlet and JSP specifications
- available patches and stability
- your deployment method, such as WAR upload or exploded app directory
If the app is simple, a ready-made install is usually the easiest option. If the project needs a specific build, a manual setup may be more appropriate, but it should still stay within the supported hosting model.
Service status and startup behavior
Tomcat must be running for the app to respond. In Plesk, service control is a key operational setting. If the service is stopped, restarting, or stuck after a failed deployment, the site may appear down even when files are present.
Check:
- whether the Tomcat service is running
- if the service starts automatically after reboot
- whether a recent deploy caused startup errors
- if the service user has access to the app files
For hosted Java apps, knowing how to start, stop, and restart the service from Plesk is often the fastest way to recover from a bad deployment.
Apache and Tomcat routing settings
One of the most common sources of confusion is the boundary between Apache and Tomcat. Apache handles the external web traffic, while Tomcat processes Java web application requests. If the routing is wrong, you may see static content but not JSP pages, or the app may load under one path but fail under another.
Proxy or connector configuration
The hosting platform must route the right requests to the Tomcat instance. In a typical setup, Apache serves the main site and proxies application requests to the private JVM or application server port.
Make sure the following are consistent:
- the Apache vhost points to the intended domain
- the Tomcat connector or proxy target matches the current service port
- the app context path is correct
- HTTPS requests are forwarded without breaking redirects
A wrong connector setting can look like an application bug, but in practice it is often a hosting configuration issue.
Context path and base URL
Tomcat applications run under a context path. That may be the root path, such as /, or a subpath such as /app. If the context path does not match what the application expects, links, API endpoints, and login redirects may fail.
Review:
- the deployed WAR file name
- the configured context path
- any rewrite rules or redirect rules in the domain settings
- the URLs used inside the application
When possible, keep the base URL simple. Fewer redirects usually means fewer problems with cookies, session handling, and absolute links.
File management settings that can break deployment
Tomcat deployment depends heavily on file structure. Even when the app code is correct, a wrong folder, missing permission, or incomplete upload can prevent startup. In Plesk, domain and file management settings are therefore just as important as service settings.
File ownership and permissions
Tomcat needs read access to application files and write access to logs, temp data, or upload directories if the app uses them. If permissions are too strict, the app may fail during startup or when handling user uploads.
Verify that:
- the service user can read the deployed WAR or exploded app directory
- temporary and log directories are writable where needed
- uploads are stored outside the public code directory if appropriate
- permissions remain consistent after a manual upload or restore
WAR deployment versus exploded directory
Both deployment styles are common. A WAR file is easier to upload and replace. An exploded directory is easier to inspect and adjust, but it may be more sensitive to incomplete file transfers.
Choose the method based on your workflow:
- WAR file for clean redeploys and simpler updates
- exploded directory for debugging or custom file-level changes
- consistent naming to avoid deploying to the wrong context
- backup before replacing a live app
Static assets and application resources
Many Java apps mix Tomcat-served pages with static files such as images, CSS, and JavaScript. In hosting environments, those files may be served by Apache or by Tomcat depending on the path and configuration.
Check that:
- static assets are uploaded to the right directory
- relative paths work from the deployed context
- caching rules do not serve old files after a release
- the app does not depend on files stored only in a local dev path
Resource limits that influence a Tomcat app
On shared hosting or managed private JVM hosting, resource limits matter even when the app itself is light. My App Server is suitable for Java hosting, Tomcat hosting, JSP hosting, servlet hosting, and small to medium private JVM use cases, so it is important to stay within the available limits.
Memory and JVM heap
Tomcat and the JVM need memory for class loading, sessions, caching, and request processing. If heap limits are too low, the app may slow down, throw out-of-memory errors, or restart under load.
Watch for:
- high memory use during startup
- memory spikes after deploying large WAR files
- session-heavy traffic
- leaks caused by code or third-party libraries
Do not increase memory blindly. Start with the app’s real needs and stay within the hosting service limits.
CPU and thread usage
Even small applications can overload a Tomcat instance if they create too many threads or handle long-running tasks incorrectly. If the hosting account has CPU limits, a busy servlet or scheduled job can slow down the site for everyone in that account.
Practical checks:
- avoid blocking tasks inside request handlers
- move long jobs outside the web request path
- review thread pool settings if the app is configurable
- watch for repeated retries or error loops
SSL, redirects, and host headers
For modern web apps, HTTPS is not optional. In a Plesk hosting environment, the SSL certificate, redirect rules, and host header behavior must all work together, especially when Tomcat generates absolute URLs or secure login redirects.
SSL certificate assignment
Confirm that the certificate is installed for the correct domain and any relevant aliases. If the certificate is attached to the wrong host name, users may see browser warnings or be redirected to an unsecured address.
HTTP to HTTPS redirects
Redirects should be simple and predictable. A common issue is a double redirect between Apache and Tomcat, or a loop created by conflicting rules.
Check whether the redirect is configured at:
- the Plesk domain level
- Apache rewrite rules
- application-level redirect logic
Use only one clear redirect strategy where possible.
Forwarded host and protocol
Applications that build absolute URLs, session cookies, or callback endpoints often need the original host and protocol information. If Apache forwards requests to Tomcat, verify that the proxy preserves the needed headers so the app knows whether the request came through HTTPS and which domain is in use.
Logs you should check first
When a Tomcat app fails, logs usually reveal whether the issue is in the domain setup, application code, Java version, or service configuration. In a hosting panel, logs are one of the most practical tools available.
Tomcat logs
Check the Tomcat startup and application logs for:
- class loading errors
- port conflicts
- permission problems
- failed context deployment
- Java version incompatibility
Apache and domain logs
Apache logs help confirm whether the request reaches the web server, whether the domain is routed correctly, and whether proxying to Tomcat is working. If the Tomcat log is quiet but the browser shows an error, Apache may be rejecting the request before it reaches the app.
Application-specific logs
If your app writes its own logs, keep them in a readable location and rotate them when needed. Application logs often show configuration mistakes, database issues, or missing environment variables that are not visible in the generic server logs.
Practical checklist for a Tomcat domain in Plesk
Use this checklist when a Tomcat site is not loading as expected:
- Confirm the domain points to the correct hosting subscription.
- Check the document root and deployment path.
- Verify that the right Tomcat version is installed.
- Confirm the selected Java version matches the app requirement.
- Make sure the Tomcat service is running.
- Review Apache routing or proxy settings.
- Check the context path and base URL.
- Inspect file permissions for the app directory and writable folders.
- Validate SSL certificate assignment and redirect rules.
- Review Tomcat, Apache, and application logs.
Common symptoms and what they usually mean
Site opens, but JSP pages do not work
This often points to a Tomcat routing issue, an incorrect servlet container version, or a deployment that only partially reached the app server.
Browser shows a redirect loop
Usually caused by a conflict between Apache redirect rules, application-level redirects, or HTTP/HTTPS handling.
WAR deploys, but the app returns 404
The context path, document root, or deployed folder name may not match the URL you are using.
App starts after restart, then stops later
This can indicate a memory limit issue, file permission issue, or a crash inside the application during traffic spikes.
Static files load, but API requests fail
That usually means the request is reaching Apache but not Tomcat, or the proxy path is wrong.
When to change settings and when not to
Not every error requires a hosting change. If the app code has a bug, changing the domain settings may only hide the real issue temporarily. At the same time, many Tomcat problems in a Plesk environment are actually caused by small hosting mismatches.
Change hosting settings when you see:
- wrong domain or alias mapping
- incorrect Java runtime selection
- Tomcat service not starting
- proxy or connector mismatch
- permissions blocking deployment
Review application code first when you see:
- errors only after a specific form submission
- stack traces in the application log
- database-related failures
- logic errors that appear regardless of host settings
FAQ
Which hosting setting is the most important for a Tomcat app?
The most important settings are the Java version, Tomcat service status, domain routing, and document root. If any of those are wrong, the app may not start or may be reachable under the wrong URL.
Can I run a Tomcat app from a standard Plesk domain?
Yes, if the hosting platform supports Java hosting through a control panel extension such as My App Server. The domain must be configured so Apache and Tomcat work together correctly.
Why does my WAR file upload but the app still does not open?
The most common reasons are a wrong context path, a stopped Tomcat service, a Java version mismatch, or file permission problems. Check the logs first.
Do I need a separate JVM for every app?
Not always, but a private JVM can help isolate a small or medium application from other workloads in the same account. It also makes Java version management easier.
What should I check after changing the Java version?
Restart the Tomcat service, review the startup logs, confirm the app still deploys, and test the main pages, login flow, and any APIs that use Java libraries with version-specific behavior.
Is Tomcat enough for enterprise clustering?
Not in this hosting model. The focus here is practical Java hosting for small and medium applications, with control through Plesk and a private Tomcat or JVM. Heavy clustering and complex high-availability architectures are not the intended use case.
Final checklist before going live
Before you publish a Tomcat app in Plesk, make sure the following are in place:
- the correct domain and subdomain are assigned
- the document root matches the deployment path
- the chosen Java version is compatible
- the Tomcat service starts cleanly
- Apache forwards traffic correctly
- SSL and redirects are configured once, not in conflict
- permissions allow the app to read and write where needed
- logs are available for quick troubleshooting
In a Plesk-based Java hosting environment, these hosting settings matter more than many people expect. A Tomcat app is usually stable once the domain, service, Java runtime, and file layout are aligned. If you manage those items carefully, deployment becomes much easier and troubleshooting becomes far faster.