If you are hosting a Java application on a managed hosting account with My App Server, deploying a WAR file is usually a straightforward process. In a Plesk-based environment, the main tasks are to prepare the application, upload the WAR package, make sure the correct Tomcat or Java version is selected, and restart the service so the application is unpacked and loaded correctly.
This guide explains how to deploy a WAR file on Tomcat hosting, how to verify the deployment, what to check if the application does not start, and how to update an existing application without breaking the service. It is written for shared hosting and private JVM setups where you manage your own Tomcat instance through a control panel rather than through a full enterprise application server platform.
What a WAR file is and how Tomcat uses it
A WAR file (Web Application Archive) is a packaged Java web application. It typically contains compiled classes, JSP files, libraries, configuration files, and static assets in one deployable archive. Tomcat can read the WAR file, unpack it into a web application directory, and serve the application under a context path.
In a hosting environment, this is often the simplest way to deploy a servlet or JSP application because you do not need to copy each file manually. You upload the WAR, place it in the correct deploy location, and let Tomcat handle the unpacking and startup.
Typical use cases include:
- JSP websites
- Servlet-based applications
- Small and medium Java web apps
- Applications that need a dedicated Tomcat instance inside a hosting account
- Java services managed from Plesk or a similar control panel
Before you deploy the WAR file
Before uploading the package, check a few important points. This avoids most deployment issues and helps the application start cleanly after the service restart.
Confirm the Java and Tomcat version
Make sure the application is compatible with the Java version and Tomcat version available in your hosting account. Some applications require Java 8, while others may need Java 11, Java 17, or a specific servlet API level.
If your hosting plan includes multiple Java/Tomcat options through My App Server, choose the version that matches the application requirements. If the application was built for an older runtime, test it against the available versions before going live.
Check the context path
The context path is the URL location where the application will be available. For example, if you deploy app.war, Tomcat may publish it as /app. If you want the application at the root of the domain, you may need to rename the WAR to ROOT.war.
Be careful when replacing an existing root application. A root deployment can overwrite the current site if it is not planned correctly.
Prepare the WAR package
Verify that the WAR file opens correctly and includes the expected structure. If the archive is incomplete or built incorrectly, Tomcat may deploy it with errors or fail to start it at all.
Useful checks before upload:
- The file is a valid WAR archive
- The application was built for the correct Java version
- Any required configuration files are included or referenced properly
- External dependencies are packaged or otherwise available on the server
- The application does not require unsupported enterprise features
How to deploy a WAR file on Tomcat hosting
The exact workflow may vary depending on how your hosting platform is configured, but the general deployment steps are the same in most Plesk and Tomcat hosting setups.
Step 1: Open the application management area
Log in to your control panel and open the Java or app server management section. In the ITA environment, this is typically handled through the My App Server extension inside Plesk.
From there, locate the Tomcat instance or private JVM that belongs to your domain or subscription.
Step 2: Select or install the correct Tomcat service
If Tomcat is not yet installed, choose one of the available Java/Tomcat versions and install it from the control panel. Some versions are available as one-click installs, while other custom versions can be uploaded and configured manually.
If Tomcat is already running, confirm that the service is active and attached to the correct domain or document root.
Step 3: Upload the WAR file
Upload the WAR file to the deployment location used by your Tomcat instance. In many setups, this is a webapps directory or a dedicated app directory managed by the control panel.
If your platform offers a deploy feature inside Plesk or My App Server, use that feature first. It usually ensures the application is copied to the right place and unpacked by Tomcat in a controlled way.
If manual upload is required, make sure:
- The file name is correct
- The file permissions allow Tomcat to read it
- The file is uploaded fully and is not corrupted
- You are placing it in the correct service directory
Step 4: Choose the application name or context
Tomcat normally uses the WAR file name as the application context. For example:
- shop.war becomes /shop
- admin.war becomes /admin
- ROOT.war becomes the root application for the domain
If the control panel allows you to define a custom app name or context path, set it according to your routing plan. This is particularly useful when hosting multiple applications under one account.
Step 5: Restart Tomcat or the app service
After uploading the WAR file, restart the Tomcat service or use the service control action provided by the control panel. This is often required so the application is unpacked, initialized, and registered correctly.
In a managed hosting environment, service restart is usually available through the control interface rather than through shell access. That makes it easier to manage the application without handling low-level server commands.
Step 6: Verify the deployment in a browser
Open the application URL in a browser and confirm that it loads successfully. If the app is deployed as /shop, visit the corresponding path on your domain. If it is deployed as the root application, check the main domain URL.
Test key pages and forms, not just the homepage. Many deployment issues only appear after the first servlet request or JSP rendering.
Deploying to ROOT.war for the main domain
If you want the application to run at the top level of the site, use ROOT.war. Tomcat treats this as the root web application, so users can access it without a subdirectory in the URL.
This approach is common when the Java application is the primary website for the domain. However, use it carefully, especially if another application or default site is already in place.
Best practice for ROOT deployments:
- Back up any current root content first
- Check the domain mapping in the control panel
- Restart the service after upload
- Test static pages, JSP rendering, and servlet endpoints
How updates work when replacing an existing WAR file
Updating a deployed Java application is usually done by replacing the current WAR file with a newer version and then restarting the service. In some environments Tomcat may redeploy automatically, but in hosting control panels a manual restart is often the safest option.
Recommended update workflow
- Back up the current WAR and any external configuration files.
- Stop the service if the platform recommends it for safe replacement.
- Upload the new WAR file, using the same name if you want to keep the same context path.
- Remove old unpacked application files if the platform requires a clean redeploy.
- Restart Tomcat or the app server.
- Check the logs and test the application after the restart.
If you change the WAR file name, the context path may change too. That can break links, APIs, or reverse proxy rules. For updates, keeping the same file name is usually the simplest option.
Common deployment locations and file naming rules
Depending on the hosting setup, your WAR file may be deployed from a standard Tomcat webapps directory, a custom application folder, or a path managed by the My App Server extension. Regardless of the location, the naming rules are usually the same.
Important naming tips:
- A simple file name creates a simple context path
- Use ROOT.war only if you need the application at the domain root
- Avoid spaces and special characters in the WAR file name
- Keep names short and predictable
- Do not upload multiple WAR files with conflicting names unless you intentionally want multiple apps
How to check whether the deployment succeeded
Successful deployment is not only about whether the WAR file was uploaded. You should confirm that Tomcat unpacked the application and that the app is responding correctly.
Check the application URL
Visit the assigned context path in your browser. A working application should return the expected page, login screen, dashboard, or API response.
Review the logs
If the application does not appear, or if it loads with errors, review the Tomcat logs. Logs usually contain the first clear reason why deployment failed, such as missing libraries, permission problems, or Java version mismatch.
Look for messages about:
- Class loading failures
- Missing JAR files
- Unsupported Java syntax or runtime version
- Port conflicts
- Deployment timeout
- Permission denied errors
Confirm the service status
Make sure the Tomcat service is actually running. In managed hosting, a service may look configured correctly but still be stopped after a failed deployment. Use the service control in the panel to verify the status and restart it if needed.
Troubleshooting common WAR deployment problems
Even a valid WAR file can fail to deploy if something in the environment is not aligned with the application’s requirements. These are the most common issues in Tomcat hosting.
The application does not load after upload
If the app does not appear after uploading the WAR, check whether Tomcat was restarted. Some setups require a restart before the archive is unpacked. Also confirm that the file is in the correct deployment directory and that the filename is valid.
You get a 404 error
A 404 often means the context path is wrong or the application failed to deploy. Make sure you are visiting the right URL. If the WAR is named myapp.war, the app is usually accessible under /myapp, not the domain root.
You get a 500 error
An internal server error usually means the app started but failed during execution. Check the logs for the real cause. Common reasons include missing configuration, database connection problems, incompatible servlet libraries, or unsupported Java features.
Tomcat starts, but the app is not unpacked
Tomcat may be running, but the WAR may not have been deployed because of file permissions, a corrupt archive, or a failed extraction step. Re-upload the file, verify its integrity, and restart the service again.
Old version still appears after update
This usually happens when an older unpacked directory is still being used. In that case, remove the previous exploded application folder if your setup allows it, then upload the new WAR and restart the service.
Best practices for Tomcat WAR deployments on managed hosting
Using a few simple practices will make deployments more reliable and easier to maintain.
- Keep WAR filenames consistent between releases.
- Back up configuration files before each update.
- Use the same Java version for development and hosting whenever possible.
- Test the application after every deployment, not only after major releases.
- Monitor the logs after service restarts.
- Store database credentials and environment-specific settings outside the WAR when possible.
- Use the control panel to manage the Tomcat service instead of manual workarounds.
If your application depends on external files, uploads, or runtime configuration, make sure those assets are preserved when the WAR is replaced. The archive itself may be overwritten during updates, while separate config files should remain in a persistent location.
When to use a custom app server configuration
Some applications need a slightly different setup than a standard one-click Tomcat installation. In the My App Server environment, you may be able to use a custom Java/Tomcat version or manually configure the service for your application’s needs.
That is useful when:
- The app needs a specific Java runtime
- You want to isolate one app per JVM instance
- You need a custom Tomcat build
- The deployment requires manual tuning of the application path or service settings
This kind of setup is well suited to hosting small and medium Java applications, servlet projects, and JSP sites that need practical control without the complexity of a full enterprise platform.
FAQ
Do I need shell access to deploy a WAR file?
Not always. In a Plesk-based hosting setup with My App Server, you can often upload and manage the WAR file through the control panel and restart the service there.
Can I deploy a WAR file to the root of my domain?
Yes, if you name the file ROOT.war and your setup supports root deployment. Make sure there is no existing site content that you want to preserve.
Why does Tomcat create a folder after I upload the WAR?
Tomcat usually unpacks WAR files into an exploded application directory. This is normal and allows the server to serve the app more efficiently.
Can I run multiple Tomcat applications in one hosting account?
Yes, if your hosting plan and control panel support multiple app contexts or separate Tomcat instances. Each application should have its own path and, where possible, its own configuration.
What should I check if the deployment works on my computer but not on hosting?
Check the Java version, Tomcat version, permissions, external dependencies, and log output. Hosting environments often differ from local development machines in JVM version and file layout.
How do I update a WAR without changing the URL?
Keep the same file name and deploy it to the same context path. For example, replacing shop.war with a newer version usually keeps the application under /shop.
Conclusion
Deploying a WAR file on Tomcat hosting is usually a simple process when the Java version, Tomcat version, file name, and service control are set correctly. In a managed hosting environment with My App Server, you can upload the archive, select the appropriate Java/Tomcat setup, restart the service, and verify the application from the browser and logs.
For reliable results, keep the deployment process consistent: use clear filenames, review log files after each restart, and avoid changing the context path unless you intend to move the application. This approach works well for JSP, servlet, and Java web applications hosted in a shared or private JVM setup.