After you have built your Java application package, the next step is to deploy it into your hosting environment and make sure the application server can run it correctly. In a managed hosting setup with Plesk and a Java extension such as My App Server, this usually means uploading a WAR file, a compiled application package, or the application files expected by your Tomcat instance, then configuring the service and testing the deployment.
The exact steps depend on whether you are using one of the ready-made Java/Tomcat versions available in the control panel or a custom application server setup that you uploaded manually. In both cases, the goal is the same: place the build package in the correct location, ensure the right Java version is selected, and verify that the app starts without path, permission, or runtime issues.
When to upload a build package for Java hosting
A build package is typically used when your application is already compiled and ready to run. In Java hosting, this often applies to:
- WAR deployments for web applications
- Servlet and JSP applications packaged for Tomcat
- Applications that need a private JVM within a hosting account
- Projects prepared in a CI/CD pipeline and uploaded after each release
- Updates to an existing hosted application without changing the full server setup
If your hosting plan includes a control panel such as Plesk with My App Server, the deployment process is usually simpler than managing a standalone server. You can install a Tomcat version, upload your build package, and control the service from the panel without handling the underlying server stack manually.
Before you upload the package
Before deployment, confirm that the package is compatible with the Java runtime and application server version in your account. This avoids common startup errors and failed deployments.
Check the package format
Most Java web applications hosted on Tomcat are deployed as a WAR file. In some workflows, you may also upload an expanded application directory or application-specific archive. For hosted Java environments, WAR remains the most common and practical choice because it is easy to replace during updates.
Verify Java and Tomcat compatibility
Make sure the build was compiled for a Java version supported by your hosting service. If your account offers multiple Java/Tomcat versions, choose the one matching your application requirements. A package built for a newer Java release may not run on an older runtime.
Confirm application configuration
Check whether your application expects environment variables, database connection settings, external configuration files, or context path values. When using managed hosting, it is common to store sensitive settings outside the build package and reference them from the application server configuration.
Prepare a backup of the current release
If you are replacing an existing application, create a backup of the current package and any related configuration. Even in a controlled hosting environment, it is good practice to preserve the previous version so you can roll back quickly if the new build needs correction.
Typical deployment flow in Plesk with My App Server
In a Java hosting environment built around Plesk and My App Server, deployment usually follows a simple flow: install or select the application server, upload the build package, assign the application to the correct path, and restart or reload the service if needed.
1. Open the Java hosting service in the control panel
Sign in to your hosting account and open the Java or application server section in Plesk. Depending on your plan, you may see a service list, a control page, or a deployment interface for Tomcat and private JVM management.
2. Select the Java/Tomcat version
If your hosting package provides several ready-to-use versions, select the one that matches your application build. This is especially important when the application depends on a specific servlet API level or Java runtime behavior.
For custom application server setups, confirm that the uploaded version has been configured correctly before continuing with deployment.
3. Upload the build package
Upload the WAR file or other supported package through the control panel or the file manager provided by your hosting platform. If your workflow uses SFTP or another secure file transfer method, transfer the file to the designated application directory.
Use a descriptive file name when possible. A versioned name such as myapp-1.8.2.war makes it easier to track releases and identify the active build.
4. Place the package in the application directory
The package must be placed in the location expected by the application server. In Tomcat-based hosting, this is often the web application deployment directory or a service-managed folder connected to your site or subdomain. If the package is uploaded to the wrong path, the service may not detect it.
When in doubt, check the application server settings in Plesk or the service control page to confirm the deployment target.
5. Deploy or activate the package
Depending on the setup, the upload may trigger automatic deployment, or you may need to click a deploy, restart, or reload action. In some managed hosting environments, the service monitors the application directory and picks up the new WAR file automatically after upload.
6. Restart the service if required
If the application does not load the new version immediately, restart the Tomcat service or the private JVM from the control panel. This clears the running state and ensures the new package is loaded correctly.
7. Test the application URL
After deployment, open the application URL and check the main page, login flow, API endpoint, or any other critical page. A successful file upload does not always guarantee a successful runtime deployment, so testing is an essential step.
How to deploy a WAR file safely
For most Java hosting use cases, a WAR file is the most efficient deployment format. It is portable, easy to update, and well suited to Tomcat hosting and servlet hosting.
Recommended WAR deployment steps
- Build the project in your CI pipeline or local build environment.
- Validate the WAR locally if possible.
- Rename the file with a clear version number.
- Upload it to the correct application directory.
- Wait for automatic deployment or restart the service.
- Check logs for startup messages and errors.
- Open the application in a browser or use a health check endpoint.
If your application server uses a context path based on the file name, changing the WAR name may change the URL path. This is useful for versioned deployments, but you should plan it carefully to avoid broken links or unexpected routing changes.
Deploying updated builds without downtime surprises
Managed hosting simplifies application management, but a build update can still create short interruptions if the deployment is not planned. A clean release process reduces risk and makes rollbacks faster.
Use versioned releases
Keep each release clearly labeled. Avoid overwriting files without a backup. A versioned release history makes it easier to identify which build is currently live and which one should be restored if needed.
Separate configuration from code
Do not hardcode server paths, passwords, or environment-specific values into the application package. Store them in configuration files, service settings, or environment variables supported by your hosting setup. This makes the same build easier to deploy across test and live environments.
Check logs immediately after upload
Review the application and server logs after each deployment. Common issues such as missing libraries, incompatible Java versions, or invalid context settings are usually visible in the log output. Early log review saves time and reduces repeated restarts.
Keep a rollback copy ready
If the new build fails, you should be able to restore the previous version quickly. A simple rollback strategy in hosted Tomcat environments is to keep the last working WAR file and redeploy it if needed.
Manual upload versus automatic deployment
Depending on the hosting platform and My App Server configuration, you may use either manual upload or a more automated release workflow.
Manual upload
Manual upload is best when you want full control over the exact package that is deployed. It is common in smaller projects and in hosting environments where the administrator prefers to manage each release explicitly.
Advantages include:
- Clear control over the package version
- Simple rollback to a previous file
- Easy verification before activation
Automatic deployment
Automatic deployment is convenient when the control panel watches a directory and deploys new builds after upload. This can reduce manual steps and help teams release faster, especially when using a repeatable CI process.
Advantages include:
- Fewer manual actions
- Faster release workflow
- Less chance of forgetting a restart or activation step
Even when automatic deployment is available, it is still important to validate the build package before upload and confirm the service status afterward.
Common deployment problems and how to fix them
Most deployment issues in Java hosting are not caused by the upload itself, but by version mismatch, path issues, or missing application dependencies.
The application does not start
If the application fails to start after upload, check the service logs first. Common reasons include incompatible Java version, broken package structure, missing classes, or failed initialization of external resources.
The old version still appears
This often means the application server has not reloaded the package yet, or the browser is showing cached content. Restart the service if needed and clear the browser cache before testing again.
404 error after deployment
A 404 error usually indicates a wrong context path, wrong file name, or incorrect placement of the build package. Confirm that the package was uploaded to the expected directory and that the deployed path matches the URL you are testing.
Database connection fails
If the package deploys but the application cannot connect to the database, verify the connection string, credentials, and host settings. Hosted Java applications commonly use external database settings that must be updated separately from the build package.
Permission or file access errors
Some applications need read/write access to temporary files, uploads, or log directories. Make sure the hosting service allows the application to write to the required locations within the account limits.
Best practices for Java hosting deployments
Good deployment habits make hosted Java applications more reliable and easier to maintain. These practices are especially useful in shared hosting environments with private JVM or Tomcat management.
- Use a consistent release naming convention
- Test the build before uploading it to production
- Keep configuration external to the application package
- Review logs after every release
- Use the correct Java version for the application
- Keep a backup of the last known working release
- Deploy during low-traffic periods when possible
If your hosting service provides service control in the panel, use it to confirm that the application server is running normally after deployment. In a managed setup, the service controls are often the fastest way to verify whether the package has loaded correctly.
How this fits Tomcat hosting and private JVM hosting
Uploading a build package is a standard part of Tomcat hosting and private JVM hosting. For small and medium Java applications, this model is practical because it gives you control over the runtime while keeping the administration simple.
With My App Server, you can run your own Apache Tomcat instance inside the hosting account, choose from available Java versions, and manage the service through Plesk. That makes it suitable for applications that need a predictable deployment process for WAR, JSP, and servlet-based projects.
This approach is focused on practical hosting needs rather than complex enterprise application server management. It works well for straightforward deployments where you want a private runtime, simple service control, and an easy way to upload and update builds.
FAQ
What file should I upload for a Java web application?
In most cases, upload a WAR file. It is the standard format for Tomcat-based Java web applications and the most convenient package for hosted deployments.
Do I need to restart Tomcat after uploading a new build?
Sometimes yes. Some hosting setups detect the new package automatically, while others require a manual restart or reload from the control panel.
Can I change the Java version after deployment?
Yes, if your hosting plan and control panel support multiple Java versions. However, changing the runtime may affect compatibility, so test the application after switching versions.
Why does my updated build not appear online?
The most common reasons are caching, wrong deployment path, missing restart, or an incorrect package name. Check the application logs and confirm that the correct build was uploaded.
Can I use a custom application server version?
Yes, if your hosting environment supports it. In My App Server setups, custom application servers can be configured separately from the ready-made versions, depending on your plan and permissions.
Is this suitable for large enterprise clusters?
This hosting model is designed for practical Java hosting, Tomcat hosting, and private JVM use in shared or managed environments. It is not intended as a replacement for complex enterprise cluster architectures.
Conclusion
To deploy a build package for Java hosting, make sure the application is compiled for the correct Java version, upload the package to the right application directory, activate or restart the service if needed, and test the deployed URL right away. In a Plesk-based environment with My App Server, this process is usually straightforward and well suited to WAR, JSP, servlet, and smaller Tomcat applications.
When you follow a clear release workflow, keep backups, and review logs after each deployment, you reduce risk and make updates easier to manage. For most Java hosting accounts, that is the most reliable way to publish new builds while keeping control over the runtime and service behavior.