When you deploy a build package to Tomcat hosting, the goal is to get your application into the correct runtime with as few manual steps as possible while still keeping the release safe and repeatable. In a managed hosting environment with Plesk and My App Server, that usually means preparing a WAR or packaged application directory, uploading it to the right location, and then using the control panel to reload or restart the Tomcat service if needed.
This guide explains the typical deployment flow for hosted Java applications, including Tomcat web apps, JSP-based sites, and servlet projects. It is written for shared hosting accounts that include a private JVM or Apache Tomcat instance managed through Plesk, where you want practical control without maintaining a full enterprise application platform.
What a build package means in Tomcat hosting
A build package is the compiled output of your Java application, ready to run on the server. In Tomcat hosting, this is often a .war file, but it can also be an exploded application directory or a release bundle that includes static assets, configuration templates, and deployment metadata.
In a managed hosting setup, the most common package types are:
- WAR files for standard Java web applications.
- Exploded deployments for applications uploaded as a folder structure.
- Application bundles that include a WAR plus external configuration or supporting files.
If you are using My App Server in Plesk, the package is deployed into the Java hosting runtime assigned to your account. That runtime may use a private Tomcat instance, a selected Java version, and service controls that let you start, stop, or restart the application server without affecting other sites on the platform.
Before you upload: prepare the package correctly
Most deployment problems happen before the file is uploaded. A clean package reduces restart failures, broken class loading, and missing resource errors.
Check the target Java version
Make sure the application was compiled for a Java version supported by your hosting plan and selected runtime. If your project was built with a newer JDK than the one available in Plesk, Tomcat may refuse to start the app or fail when loading classes.
Common checks:
- Confirm the project’s source and target compatibility.
- Verify the Java version set for your private JVM or app server.
- Test the package locally with the same Java level if possible.
Use a release-ready WAR or package
A deployment package should contain only files required for runtime execution. Avoid including development artifacts such as source code, IDE metadata, temporary logs, or test resources unless your application genuinely needs them.
A practical release package normally includes:
- Compiled classes and libraries.
- Web resources such as JSP, HTML, CSS, and JavaScript.
- Deployment descriptors, where required.
- Application-specific configuration that is safe to publish.
Externalize sensitive settings
Do not hardcode passwords, API keys, or environment-specific connection strings into the build package if they can be stored separately. In managed Tomcat hosting, it is usually better to keep sensitive values in server-side configuration, environment variables, or protected config files that are not part of the public web root.
Test the package locally
Before upload, run the application in a local or staging Tomcat instance with the same major version if possible. Check that:
- The app starts without classpath errors.
- All database connections work.
- Static assets are loading correctly.
- No files are expected in writable paths that do not exist on hosting.
Where to upload the build package in Plesk
In a hosting platform with Plesk and My App Server, the upload target depends on how your Java app server is configured. The deployment point is usually associated with the Java application instance, not the generic website document root used for static sites.
Typical upload locations and methods include:
- The application deployment area shown in the Java hosting extension.
- A dedicated file manager location for the Tomcat web application.
- SFTP or FTP access to the hosting account, followed by deployment through the control panel.
- Direct upload through the Plesk file manager if enabled for the account.
For hosted Tomcat deployments, the safest approach is to use the location assigned by the control panel rather than manually placing files into arbitrary directories. This helps avoid path mismatches and permission problems.
How to deploy a build package for Tomcat hosting in the UK
Use the following workflow to publish your application package in a managed Tomcat hosting environment.
Step 1: Open the Java application service in Plesk
Sign in to your hosting control panel and open the My App Server or Java hosting section for the relevant subscription. From there, identify the Tomcat instance or private JVM attached to your application.
Make sure you are working with the correct site or subscription, especially if you host multiple applications under one account.
Step 2: Stop or pause the service if the application is actively serving traffic
If the app is in production use, stop the service or place the site into maintenance mode before replacing the package. This reduces the risk of users hitting partially updated classes or stale resources during upload.
For small applications with low traffic, a brief restart window may be enough. For more sensitive applications, prepare a maintenance page or schedule the deployment during off-peak usage.
Step 3: Upload the new WAR or package
Upload the release file to the deployment path provided by the hosting panel. If you are replacing an existing application, confirm whether the platform expects:
- A full overwrite of the previous WAR.
- A versioned file name.
- An exploded directory update.
When possible, use a clean file name for each release, such as app.war for the active version, and keep archived versions separately for rollback.
Step 4: Remove stale files if the deployment method requires it
If your application uses an exploded directory or if Tomcat keeps unpacked files from an older release, remove any obsolete files that are no longer part of the new build. Old JSPs, classes, or static files can remain accessible if they are not cleaned out properly.
This is especially important when you rename classes, move resources, or remove endpoints. Stale cached files may make the application appear updated when parts of the old release are still being served.
Step 5: Deploy or reload the application
Use the control panel action for deployment, service restart, or application reload. In a Tomcat hosting setup managed by Plesk, restarting the service often triggers unpacking of the WAR and loading of the new classes.
After restart, confirm that:
- The service starts successfully.
- The app responds on the expected URL.
- Logs do not show startup errors.
- Database and external integrations connect correctly.
Step 6: Verify the version that is live
Always check that the deployed version is the one you intended to publish. A simple version marker in the footer, an /about endpoint, or a build timestamp in the logs can help confirm the release.
If you have more than one Tomcat app or multiple environments, verify the exact host, application context, and Java runtime before declaring the deployment complete.
Recommended deployment patterns for hosted Tomcat apps
Not every application should be deployed in the same way. The best method depends on how your project is built and how often you release new versions.
WAR-based deployment
This is the most straightforward method for Tomcat hosting. Build the WAR in your CI system or build tool, upload it to the assigned app location, and restart the service if needed. This works well for JSP, servlet, and traditional Spring-style web applications that fit into a standard servlet container.
Exploded directory deployment
An exploded deployment can be useful during development or for apps that need file-level changes. However, it requires more care because partial uploads may leave the app in an inconsistent state. If you use this method, upload the complete directory structure and then reload the service only after the transfer is finished.
Versioned release files
For safer rollback, keep release packages with version numbers and activate one release at a time through the deployment path used by the control panel. This makes it easier to compare builds and restore a previous working version if a new package causes a runtime issue.
Common problems after uploading a Tomcat build package
Even when the upload succeeds, the application may not start correctly. These are the most common issues in managed Java hosting.
Context path mismatch
If the application is published under the wrong path, the site may return 404 errors or load an unexpected page. Check the application context configured in the control panel and make sure it matches the deployed package name or the path defined in the Tomcat configuration.
Wrong file permissions
Tomcat needs read access to application files and, in some cases, write access to temporary or upload directories. If permissions are too restrictive, the app may fail during startup or when writing session data.
Java version incompatibility
Classes compiled for a newer Java release may fail on an older runtime. If your build uses recent language features, verify that the selected private JVM in Plesk supports them.
Missing external resources
Database drivers, cache settings, file paths, or API endpoints may not exist in the hosting environment. Review application logs carefully after deployment to identify missing dependencies or incorrect configuration.
Old unpacked files still being served
If the previous release was unpacked by Tomcat, old files can remain until the application directory is cleaned. This can lead to confusing behavior where some pages reflect the new release while others still use the old one.
How to reduce deployment risk
For hosted applications, especially smaller Tomcat deployments that need stability more than complex orchestration, simple release discipline is usually the best approach.
- Upload during a low-traffic window.
- Keep a known-good previous build available for rollback.
- Use a clear versioning scheme for release files.
- Review logs immediately after each deploy.
- Test critical user flows after the service restarts.
If your app uses a database migration step, run the schema update in a controlled order. First deploy the compatible application version, then apply data changes if needed, and only then bring the site fully back online.
Using logs to confirm a successful deployment
Logs are one of the most useful tools in Tomcat hosting. After uploading a build package and restarting the service, check the application and Tomcat logs for:
- Startup exceptions.
- Missing class or library errors.
- Database connection failures.
- Configuration parsing errors.
- Deployment warnings about resource paths.
A clean startup log and a working homepage are good signs, but you should also test any login, form submission, upload, or API endpoints that are important to your application.
Example release workflow for a typical Tomcat app
A practical example helps show how the process fits together in a managed hosting account.
- Build the application as a WAR file using your standard build tool.
- Confirm the WAR matches the Java version available in the hosting panel.
- Take a backup of the current release package.
- Stop the Tomcat service from Plesk or enable maintenance mode.
- Upload the new WAR to the assigned deployment location.
- Remove old unpacked files if the previous release used an exploded deployment.
- Start or restart the service.
- Check the logs and open the site in a browser.
- Test login, database access, and any critical paths.
This workflow is simple, but it works well for many Java web applications hosted on shared infrastructure with a private JVM.
When to use a custom app server configuration
Some applications need a specific Tomcat version, custom JVM options, or a modified server setup. In My App Server, this is generally handled through the hosting control panel rather than by installing a full enterprise stack manually.
A custom app server setup may be useful when:
- Your application needs a different supported Java version.
- You want to run a specific Tomcat release.
- You need isolated runtime settings for one hosted app.
- You need to adjust service behavior through the panel.
Keep the configuration practical and within the boundaries of the hosting platform. For small and medium Java applications, this gives enough flexibility without requiring a large dedicated middleware environment.
FAQ
Can I deploy a Java build package without SSH?
Yes, in many managed Tomcat hosting setups you can upload and deploy through Plesk, the file manager, or the Java hosting extension without SSH access. SSH can be helpful, but it is not always required.
Should I upload a WAR file or a folder?
For most Tomcat hosting cases, a WAR file is the simplest and safest option. Use an exploded folder only if your deployment process specifically requires it.
Do I need to restart Tomcat after every upload?
Often yes, especially if you replace the active WAR or update application classes. Some control panel setups may support redeploy or reload actions that are faster than a full restart.
Why does the old version still appear after deployment?
This usually happens because of cached files, unpacked old content, browser cache, or a deployment path issue. Clear the old application files, confirm the context path, and check whether Tomcat needs a restart.
Can I use the same process for JSP and servlet apps?
Yes. JSP and servlet applications are typically deployed the same way as other Tomcat web apps, especially when they are packaged as WAR files.
What should I do if the app fails to start after upload?
Check the logs first. Look for Java version mismatches, missing libraries, permission errors, and incorrect configuration values. If needed, roll back to the last known-good build and redeploy after fixing the package.
Conclusion
Deploying a build package for Tomcat hosting in a managed UK-focused environment is mostly about getting the package format, Java version, and control panel workflow aligned before you publish. With My App Server in Plesk, you can manage a private Tomcat instance, choose the right Java runtime, upload a WAR or application bundle, and control the service from one place.
For the best results, keep releases clean, test locally, deploy through the assigned hosting path, and verify logs after each update. That approach is usually the most reliable way to publish Java, JSP, and servlet applications on shared Tomcat hosting without unnecessary complexity.