If your application is already built into a deployable package, uploading it to a Tomcat hosting environment is usually the fastest way to publish a new version. In a managed hosting setup with Plesk and a Java extension such as My App Server, you can keep the deployment process simple: prepare the build, upload the package, assign it to the correct application server, and restart the service only when needed.
This guide explains how to deploy a build package for Tomcat hosting in a practical way. It is written for hosted Java, JSP, servlet, and WAR-based applications running on a private JVM or private Tomcat instance inside a hosting account. The steps below are especially useful when you use a control panel workflow instead of a full DevOps stack.
What a build package is in Tomcat hosting
A build package is the deployable output of your Java application. In Tomcat hosting, this is usually one of the following:
- WAR file - the most common format for Tomcat applications.
- Expanded application directory - a folder structure containing your compiled classes, libraries, web resources, and configuration.
- Custom package archive - a ZIP or similar archive that you unpack before deployment, depending on your workflow.
For most hosted Tomcat environments, WAR is the preferred format because it is easy to upload, version, and replace. If your project includes JSP, servlets, or a standard web application structure, WAR deployment is usually the cleanest option.
In a hosted environment with My App Server, the build package is typically assigned to a specific Java application instance. That instance runs on its own JVM and Tomcat version selected in Plesk, which makes deployment more controlled than placing files directly into a generic web directory.
Before you upload the package
Good deployment starts with a clean build. Before uploading anything, make sure the package is ready for the Tomcat runtime and the hosting account limits.
Check the Java and Tomcat version
Your build must be compatible with the Java version and Tomcat version configured for the application server. A package compiled for a newer Java release may fail if the hosted JVM is older. The same applies to Tomcat APIs and servlet specifications.
If you are using a managed hosting platform with multiple ready-made Java options, confirm that the selected version matches your build requirements before deployment.
Validate the application structure
For WAR deployment, confirm that the archive contains the correct structure:
WEB-INF/directory- compiled application classes
- library JAR files in
WEB-INF/lib - JSP, HTML, CSS, and other web assets
- deployment descriptors if your app uses them
Missing folders, duplicated root paths, or wrong file placement can cause 404 errors, startup failures, or class loading issues.
Review configuration values
Before uploading, check whether your package depends on environment-specific values such as:
- database connection strings
- API keys
- SMTP settings
- filesystem paths
- session or cache settings
In hosting environments, these values are often best managed outside the package or injected through application configuration, so you do not need to rebuild the package every time a setting changes.
Confirm resource limits
Shared hosting Java environments usually have practical limits on memory, CPU usage, disk space, and process behavior. If your package is too large or your app needs more memory than the assigned JVM can use, deployment may succeed but the application may still fail at runtime.
Check your hosting plan limits and align the package size, memory usage, and startup requirements accordingly.
How to deploy a build package in Plesk
The exact buttons and names may differ depending on the hosting platform, but the deployment process in Plesk-based Java hosting usually follows the same pattern.
1. Open the Java application management area
Sign in to Plesk and open the section used for Java application management. In an environment powered by My App Server, this is where you will manage the private JVM, Tomcat instance, version selection, and service control.
Choose the target application server where the package should be deployed. If you host multiple apps, make sure you are working in the correct subscription, domain, or application slot.
2. Select the Tomcat instance or application slot
If your hosting account supports multiple Java services, pick the specific Tomcat instance that should run the build. This is important when you keep separate environments for development, testing, and production-like usage.
Uploading to the wrong application slot can overwrite the wrong version or start the application with the wrong context path.
3. Upload the build package
Use the upload option in the control panel to send the WAR file or package archive to the server. Depending on the interface, you may upload:
- directly through the browser
- through file manager
- through FTP or SFTP if that is your preferred workflow
If the platform supports direct package deployment, upload the WAR file to the designated deployment area rather than a general web root. Tomcat will typically unpack and manage the application from its own runtime path.
4. Assign the package to the application
After upload, connect the package to the Tomcat application instance. This usually means choosing the archive, confirming the app context, and saving the deployment settings.
In a hosted Tomcat environment, the control panel may allow you to define:
- application name
- context path
- Java version
- Tomcat version
- startup parameters
Use a clear context path if the application is meant to be accessed under a specific URL. For example, a package named app.war may be served as /app unless the platform is configured differently.
5. Deploy or redeploy the package
Once the archive is attached to the Tomcat service, trigger deployment or redeployment. This tells the application server to unpack the package, load classes, and start the web application.
If you are replacing an existing version, make sure the old application is stopped cleanly before you publish the new package. This reduces the risk of file locks, partially updated resources, and inconsistent session state.
6. Restart the service if required
Some changes can be applied without a full restart, while others require restarting the Tomcat service or private JVM. For example, changes to Java version, JVM options, or some runtime settings usually need a restart.
Use the service control tools in the hosting panel only when needed. Frequent restarts are not ideal for live traffic, but a controlled restart is often the safest way to apply a new build package cleanly.
Recommended deployment workflow for WAR files
If you deploy WAR files regularly, a predictable workflow helps reduce errors. The following process is suitable for most hosted Tomcat applications.
Build the package locally or in CI
Create the WAR from a known build process, then confirm that the artifact version matches the release you intend to publish. Avoid uploading unverified files from temporary build directories.
Back up the current version
Before replacing a working application, keep a copy of the current WAR or deployment directory. If the new build causes issues, a rollback is much faster when the previous package is available.
Upload the new package under a clear name
Use versioned file names when possible, such as myapp-1.8.3.war. This makes it easier to track which build is running and simplifies rollback if needed.
Remove or archive the old package
If your control panel keeps old archives in the deployment path, remove outdated files after confirming that the new package runs correctly. Old artifacts can confuse manual deployment processes and consume disk space.
Verify the application after deployment
Always test the deployed app by opening the site, checking the homepage, validating key forms, and confirming that backend features work. A successful upload does not always mean the application is fully healthy.
Deploying expanded directories instead of WAR
Some teams prefer to upload an expanded application directory rather than a compressed WAR archive. This can be useful when a workflow requires direct access to resources or when files are updated frequently during testing.
However, expanded directory deployment has a few trade-offs:
- more files to manage manually
- higher risk of missing resources during upload
- more chances to leave stale files from previous releases
- less convenient rollback compared with a single WAR file
If you use expanded directories in a hosted environment, make sure the upload is complete and the directory permissions are correct. The application server must be able to read all classes, libraries, and web resources.
Common deployment mistakes
Most Tomcat deployment problems are caused by small packaging or configuration errors. The list below covers the most common issues in hosted Java environments.
Wrong Java version
If the package is compiled for a newer Java runtime than the one selected in Plesk, the app may fail on startup with class version errors. Always align the build target with the hosting JVM.
Incorrect archive structure
A WAR file that contains an extra top-level directory may unpack in the wrong way. This often leads to missing JSP pages, static assets not loading, or the application starting under an unexpected path.
Missing dependencies
If the build excludes a library that the app expects at runtime, the application may deploy but fail when a request hits the missing code path. Check WEB-INF/lib and your external dependency strategy carefully.
Permission problems
The application may need read and write access to certain directories, such as upload folders or temporary storage. In managed hosting, permissions should match the platform’s security model so the private JVM can access the required files.
Stale cached files
Tomcat may keep cached classes, unpacked files, or session data between deployments. If a change does not appear after upload, clear the relevant cache or redeploy cleanly.
Incorrect context path
If the application is deployed under the wrong URL path, it may appear to be missing even though the service is running. Check the context mapping in the control panel and confirm the URL you should use.
How to deploy safely with minimal downtime
If the application is already live, the goal is to update it without unnecessary service interruption. A hosted Tomcat environment is well suited for practical, low-complexity releases when the deployment steps are clear.
Use a maintenance window if needed
For larger changes, plan the upload during a quiet period. Even a short Tomcat restart can interrupt active users, so timing matters.
Keep the previous build available
Rollback is much faster when the previous WAR or package is still accessible. A simple rollback plan is often enough for hosted Java applications that do not require complex release orchestration.
Separate configuration from code
When config lives outside the package, you can replace the build without re-entering all settings. This is one of the most practical ways to simplify Tomcat deployment in a control panel environment.
Test after every release
Check application startup logs, HTTP status, login flow, data access, and any integration points. It is easier to fix a deployment issue right after release than after users report it.
When to use a custom app server setup
Some hosted environments allow custom app server configurations in addition to ready-made Tomcat installations. This can be useful when your application needs a specific Java version or a non-standard runtime setup.
Custom app server options are usually best when you need:
- a particular Java runtime
- a tuned JVM configuration
- a separate Tomcat instance for one application
- more control over startup and service behavior
For small and medium Java applications, this gives you enough flexibility without requiring a complex enterprise platform.
Troubleshooting after upload
If the package uploads successfully but the app does not start, check the following areas in order:
- application logs in the hosting panel
- Tomcat startup logs
- Java version and Tomcat version compatibility
- package structure and file permissions
- context path and URL mapping
- database connectivity and external service access
If the app starts but behaves incorrectly, compare the deployed package with the local build. A missing class, outdated config file, or incomplete upload is often the cause.
In a private JVM hosting setup, also confirm that the service is running under the expected instance and that another deployment has not overwritten the same application slot.
FAQ
Can I deploy a Java application as a WAR file on Tomcat hosting?
Yes. WAR is the standard deployable format for Tomcat hosting and is usually the easiest option for JSP, servlet, and web application projects.
Do I need to restart Tomcat after every upload?
Not always. Some redeployments can be applied without a full restart, but changes to Java version, JVM options, or certain runtime settings often require a restart of the Tomcat service.
What should I do if the app works locally but not after upload?
Check Java compatibility, archive structure, missing dependencies, file permissions, and environment-specific configuration. Local builds often use settings that are not present on the hosted server.
Can I host more than one Java app in the same hosting account?
In many managed hosting setups, yes. You can usually create separate Java application instances or deployment slots, each with its own Tomcat configuration and package.
Is a private JVM better than a shared application environment?
A private JVM gives you more control over Java version, service behavior, and deployment isolation. It is a practical choice for small and medium applications that need a dedicated runtime inside a hosting account.
What is the safest way to update a live Tomcat application?
Keep a backup of the current build, upload the new package under a clear version, redeploy in a controlled window, and verify the application immediately after the release.
Conclusion
Deploying a build package for Tomcat hosting is straightforward when the package is prepared correctly and the control panel workflow is clear. In a managed hosting environment with Plesk and My App Server, you can upload a WAR file or application package, attach it to the correct Tomcat instance, and start the service with minimal manual work.
The key points are simple: match the Java version, keep the archive structure clean, use versioned builds, and verify each release after deployment. For JSP, servlet, and standard Java web applications, this approach provides a reliable and practical deployment process without the overhead of a large enterprise platform.