If you are preparing to upload a new Tomcat release in a managed hosting environment, the safest approach is to check compatibility, service settings, filesystem permissions, and your current deployment method before you replace any files. On a shared hosting account with Plesk and a Java hosting extension such as My App Server, a new Tomcat build should fit the existing control panel workflow, the selected Java version, and the limits of the account. A careful pre-upload review reduces downtime, avoids broken web apps, and makes rollback much easier if something does not start as expected.
Use the checklist below to validate the release package, confirm the runtime requirements, and prepare the hosted environment for a clean upload. The guidance is written for Tomcat hosting, JSP hosting, servlet hosting, and private JVM setups used on UK-facing hosting accounts.
Check the Tomcat version against your application requirements
Before you upload a new Tomcat release, confirm that it matches the needs of the application you host. A Tomcat upgrade can affect class loading, session handling, TLS settings, servlet behaviour, and the way your WAR file is deployed. Even if the release is marked as stable, your application may depend on a specific major or minor version.
Review framework and application compatibility
- Check the supported Tomcat branch for your Java application, JSP site, or servlet project.
- Review the minimum Java version required by the Tomcat release.
- Confirm that your application libraries are compatible with the target servlet container version.
- Look for changes in deprecated features, bundled libraries, or connector defaults.
If you use a private JVM or a custom app server setup through Plesk, make sure the selected Java version is available and supported by the Tomcat build you plan to upload. A Tomcat package that is valid on one Java runtime may fail on another.
Verify the package source and release integrity
Never upload a new release package without checking where it came from and whether it is complete. For hosted environments, the goal is to avoid broken archives, partial uploads, and tampered files. If the release is provided by your team, compare it with the official build notes or internal release manifest before deployment.
Basic integrity checks
- Confirm the archive format expected by your My App Server workflow.
- Check file size against the published release package or deployment note.
- Validate checksums such as SHA-256 when available.
- Ensure the archive opens cleanly and contains the expected Tomcat directory structure.
For UK hosting customers, it is also wise to verify that the package upload will not exceed practical account limits such as disk quota, inode usage, or upload timeouts. If the package is too large, split the deployment process into smaller steps when possible.
Review the current hosting setup in Plesk before replacing anything
In a control panel environment, the safest upgrades are done after you review the current service state. On managed hosting, Tomcat is often tied to a specific Plesk extension, service definition, and application path. Before uploading a new release, inspect the current service configuration so you know exactly what you are replacing.
What to confirm in the control panel
- The current Tomcat version and its installation path.
- The active Java version used by the service.
- The application root or deployment directory in use.
- Whether the service is currently running, stopped, or scheduled for maintenance.
- Any custom JVM flags, memory settings, or startup parameters.
If your hosting platform allows multiple Java/Tomcat versions, check whether the new release should be installed as a replacement or alongside the existing version. For many hosted Tomcat setups, keeping the previous version available simplifies rollback if the new release causes startup errors.
Check filesystem permissions and ownership
Permission problems are one of the most common causes of failed Tomcat deployments. Even when the upload itself completes, the service may not start if the webapp files, scripts, or logs are not readable and writable by the correct user. In a shared hosting account, this is especially important because the Java service usually runs under account-specific permissions.
Permission items to validate
- The Tomcat installation directory is owned by the correct account user.
- Configuration files are readable by the service process.
- Log directories are writable.
- Temporary directories can be created and used during startup.
- The deployed application files do not have restrictive permissions.
When a new release is uploaded, files may inherit different permissions from the previous build or from the upload method used. If your My App Server setup uses service control in Plesk, make sure the service can access the new archive and unpack it without permission errors.
Check Java runtime settings before the upload
Tomcat depends on the Java runtime as much as it depends on the container version. A release may technically upload correctly but still fail if the JVM settings are not suitable. Before deploying a new build, confirm that the Java version and memory allocation match the release requirements and the expected application load.
Important runtime checks
- Confirm the Java version selected in Plesk or the hosting control panel.
- Review heap size and other JVM memory settings.
- Check for custom environment variables used by the application.
- Verify whether the new Tomcat release requires a newer TLS or cryptography provider.
- Ensure no conflicting Java process is already bound to the same service port.
For small and medium Java hosting deployments, a private JVM is usually enough when it is sized correctly. Avoid copying production assumptions from large enterprise stacks unless your hosting environment is designed for them. Managed hosting works best when the runtime profile is kept clear, simple, and aligned with the application’s actual needs.
Back up the current release and configuration
Before uploading anything new, create a complete backup of the current Tomcat installation and related settings. If the release introduces a startup issue, you need a fast way to restore the previous working state. This is especially important when the hosting account runs a single Tomcat instance and a failed upload would immediately affect the live site or application.
Back up these items at minimum
- The current Tomcat directory or release archive.
- Web application WAR files or expanded application folders.
- Custom configuration files such as server.xml, context files, or application-specific properties.
- SSL, proxy, or connector-related settings if they are managed manually.
- Any startup scripts or Plesk extension settings that are not generated automatically.
Keep at least one verified rollback copy outside the active deployment path. That way, if the new Tomcat release fails to start, you can restore the old service without reconstructing the configuration from memory.
Test the release in a staging path if possible
If your hosting plan and deployment structure allow it, test the new Tomcat release in a separate directory or staging application path before switching traffic. This is the simplest way to identify configuration problems without affecting live users.
What to validate during staging
- Tomcat starts cleanly with the new binaries.
- The application deploys without compilation or classpath errors.
- Static assets, JSP pages, and servlets load correctly.
- Sessions, form submissions, and login flows behave as expected.
- Logs do not show warnings that indicate version or permission issues.
In a Plesk-based managed hosting environment, staging can be as simple as using a separate service path or a separate application instance. The key is to avoid testing a new release directly on the active production path unless you already have a proven rollback plan.
Check ports, connectors, and proxy settings
A new Tomcat release may come with configuration changes that affect connectors, ports, or the way the application works behind Apache. If the hosting account uses Apache in front of Tomcat, make sure the integration still matches the new release structure.
Connector-related checks
- Confirm that the HTTP or AJP connector settings are still valid.
- Check for conflicts with ports used by other services in the same account.
- Review proxy rules if Apache forwards requests to Tomcat.
- Ensure any custom headers or host settings still work after the update.
This is particularly important when the hosted application relies on a reverse proxy setup or a custom context path. A release that starts correctly can still break request routing if the connector configuration was not reviewed first.
Inspect logs from the previous version before replacing it
Logs often reveal problems that would otherwise be repeated after the update. Before uploading a new release, review the current Catalina logs, application logs, and startup output to see whether the old version already had warnings or unresolved issues.
Look for these warning signs
- Repeated classpath or dependency errors.
- Thread or memory warnings during startup.
- Deprecated configuration notices.
- Session persistence or file access errors.
- Connector binding warnings or port conflicts.
If the old release already showed startup instability, upgrade carefully and consider fixing the configuration issue first. Uploading a new Tomcat build on top of an unstable environment can make troubleshooting much harder.
Prepare a rollback plan before the upload
Every Tomcat release upload should have a rollback step. In hosted environments, quick recovery matters more than forcing a broken release to stay online. A rollback plan gives you a clear path if the new package fails validation after deployment.
Minimum rollback checklist
- Save the current working Tomcat archive or directory.
- Document the active Java version and JVM options.
- Record the original application path and service name.
- Keep a copy of the previous configuration files.
- Know how to restart or switch the service back through Plesk.
For small and medium Java hosting deployments, a simple and documented rollback is usually better than a complex upgrade process. The goal is to restore service quickly if the new release is incompatible or misconfigured.
Check account limits and deployment constraints
On managed hosting, resource limits can affect the upload even before Tomcat starts. Confirm the account has enough disk space, memory headroom, and process allowance for the new release. If the package includes expanded libraries or additional application assets, the final deployed size may be much larger than the archive itself.
Limits to review
- Available disk space for the release and temporary files.
- File count or inode limits.
- Memory settings available to the private JVM.
- Any execution time limits on upload or extraction tasks.
- Service restart permissions in the hosting panel.
If the account is close to its quota, clear unused archives, old logs, and obsolete deployment copies before uploading the new Tomcat release. This makes the deployment safer and reduces the risk of a failed unpack or incomplete service restart.
Recommended pre-upload checklist
Use this practical checklist before you replace a Tomcat release in a hosted environment:
- Confirm the new Tomcat version matches the application and Java runtime.
- Validate the package source and checksum if available.
- Review the current service settings in Plesk or the control panel.
- Back up the active Tomcat installation and configuration.
- Check permissions, ownership, and writable directories.
- Confirm Java version, JVM memory, and custom startup options.
- Review logs from the current release for warnings or errors.
- Verify connector, proxy, and port settings.
- Make sure disk space and account limits are sufficient.
- Prepare a rollback plan before you upload the new files.
Common mistakes to avoid
Many deployment problems come from skipping basic checks. The following mistakes are common in Tomcat hosting environments and can usually be avoided with a short pre-upload review.
- Uploading a release without confirming Java compatibility.
- Replacing a working install without a backup.
- Ignoring permission changes after unpacking the archive.
- Forgetting to review custom JVM options.
- Testing directly on the live application path.
- Assuming old connector settings will automatically fit the new version.
- Ignoring disk space and quota limits before extraction.
FAQ
Do I need to stop Tomcat before uploading a new release?
In most hosted environments, it is safer to stop the service or put the application into maintenance mode before replacing core Tomcat files. This avoids locked files, partial updates, and unpredictable startup behaviour after the upload.
Can I upload a new Tomcat version without changing my WAR file?
Yes, but you should still verify compatibility. Even if the application package stays the same, the newer container may change startup behaviour, servlet handling, or library loading. Always test after the update.
What should I check if the service does not start after the upload?
Review the logs first, then check Java version, permissions, port usage, and configuration files. In a Plesk-based managed hosting environment, also confirm that the service settings still point to the correct installation path.
Is it better to upload a new release or install it through the control panel?
If your hosting platform provides a supported install option for the Tomcat version you need, using the control panel is usually safer. Manual uploads are useful for custom versions, but they require more careful checks before and after deployment.
Can I run multiple Tomcat versions on the same hosting account?
That depends on the hosting service design and account limits. Some setups support multiple Java or Tomcat instances, while others are intended for a single private JVM. Check the available service controls before planning parallel installs.
Conclusion
Before uploading a new Tomcat release, check version compatibility, Java runtime settings, permissions, logs, package integrity, and rollback readiness. In a managed hosting environment with Plesk and My App Server, these checks are the difference between a smooth deployment and a service interruption. A small amount of preparation helps you update Tomcat confidently while keeping the hosted application stable, readable, and easy to recover if needed.