Before you put a JSP site live in Plesk, it is worth checking a few hosting and application settings so the site starts cleanly, runs on the right Java version, and behaves the same way for visitors as it did during testing. For JSP hosting, small details such as the document root, Tomcat deployment path, domain bindings, and SSL setup can make the difference between a smooth launch and a site that returns 403, 404, or application errors.
If your hosting plan includes Java support through Plesk and My App Server, you can usually prepare the site from the control panel without needing server-level access. That makes it easier to manage a private JVM, deploy a WAR file, and control the app server directly from the domain’s hosting settings.
What to check before going live
Use this checklist before you switch a JSP application from staging to production:
- Confirm the correct domain or subdomain is assigned to the application.
- Verify that the document root and deployment path are correct.
- Make sure the right Java version and Tomcat version are selected.
- Check that the application is deployed in the intended context path.
- Review SSL/TLS settings and force HTTPS if required.
- Set the proper hosting type and application handler for JSP/Tomcat.
- Test file permissions, upload paths, and any environment-specific configuration.
- Review logs before and after launch.
These steps are especially important on shared hosting accounts where the JSP application runs inside a managed environment with a private Tomcat or JVM instance.
Confirm the domain and hosting settings in Plesk
Start by opening the domain in Plesk and checking the hosting configuration. For a JSP site, the domain must point to the correct site directory and the application must be linked to the right hosting service.
Review the hosting type
In Plesk, confirm that the domain is configured for the expected hosting type. If the site uses JSP or servlets, the hosting setup should support Java execution through Tomcat or your hosting provider’s Java integration layer.
If your hosting account uses My App Server, verify that the service is enabled for the domain and that the app server is available before going live. A site may upload correctly but still fail to respond if the Java service is stopped, misconfigured, or assigned to a different application.
Check the document root
Make sure the document root matches the location where your application files are deployed. In many JSP setups, the web root is not the same as the source code root. If you upload a WAR archive or deploy compiled files, the actual public path may differ from where you store the project in your build process.
Before launch, confirm:
- the document root is set to the correct application directory;
- static assets such as CSS, JS, and images are stored in reachable paths;
- the context path matches the URL you plan to use;
- test files are not left in the live directory.
Verify the domain binding
Make sure the domain name, subdomain, and any aliases are pointing to the intended application. If you are moving from a staging site to a live domain, check that the production domain is connected to the correct hosting subscription and not still pointing to a test environment.
This is especially useful when a JSP application is deployed under a subdomain during testing and then moved to the main domain for launch.
Prepare Tomcat or My App Server for production use
For JSP hosting, the application server is the core of the deployment. If you use a private Tomcat instance through Plesk, make sure it is installed, configured, and ready before traffic reaches the site.
Select the correct Java version
Many JSP and servlet applications depend on a specific Java runtime. Before launch, check that the active Java version matches your application requirements. A project built for Java 8 may not run correctly under a newer runtime if the code or libraries are not compatible, and a newer application may not start on an older runtime.
When using My App Server, choose the version that your application has been tested against. If you have multiple supported versions available, use the one confirmed by your development team or build documentation.
Confirm the Tomcat version
Some web applications behave differently across Tomcat versions. Before putting the site live, verify that the installed Tomcat version is the one you expect. If your application uses a specific servlet API, custom web.xml settings, or session handling behavior, version mismatches can lead to startup errors or broken functionality.
If your provider offers prebuilt Java/Tomcat versions with one-click installation, use the version that best matches your application requirements. If you upload and configure a custom application server version manually, review the server logs carefully after deployment.
Check service status and startup behavior
Make sure the service is running and set up to start correctly for the live site. In a managed hosting environment, Tomcat or the Java service may be controlled from the Plesk extension, so it is important to confirm that the service starts cleanly after any configuration change.
- Start the service manually before launch if needed.
- Restart it after configuration changes.
- Confirm that it remains stable after a fresh restart.
- Check whether the application takes time to warm up on first request.
Deploy the application in the right way
JSP sites can be deployed in different formats, depending on how the project is built. The most common options are a WAR file, an exploded web application directory, or a custom application layout. Make sure the production deployment method is the same one used for testing unless you intentionally changed it.
Use the correct WAR or application folder
If your application is packaged as a WAR file, upload the final production build rather than a development build. Verify that the package contains only the files required for production, without local test data, debug pages, or temporary resources.
If you deploy as an extracted folder, check that the structure is correct. JSP files, WEB-INF, configuration files, and static assets should all be in the expected locations.
Check the context path
The context path determines the URL where the application appears. For example, the site may load at the root domain, a subdirectory, or a dedicated application path. Before going live, confirm that the context path is the one intended for the production domain.
If the production URL should be clean and simple, avoid leaving the app under a test path such as /app-test or /staging. A wrong context path often causes confusion during the launch because the site can appear “missing” even though it is deployed correctly.
Remove development-only files
Before going live, remove or disable any files that should not be public, such as:
- test JSP pages;
- sample servlets;
- debug logs stored in web-accessible folders;
- temporary upload files;
- backup archives inside the web root;
- hard-coded staging credentials;
- development-only configuration files.
Keeping the live directory clean reduces security risk and helps avoid accidental exposure of internal information.
Set up SSL/TLS and HTTPS before launch
Most live JSP sites should run on HTTPS from day one. In Plesk, check that the SSL/TLS certificate is installed for the correct domain and that the application responds properly over encrypted connections.
Install or assign the certificate
Make sure the certificate covers the main domain and any required aliases or subdomains. If the site is accessible through both www and non-www versions, confirm that the certificate includes both names where needed.
Force HTTPS if required
If the production site should only use HTTPS, enable redirection from HTTP to HTTPS. This helps prevent duplicate content issues, keeps login forms secure, and avoids mixed content errors when the browser loads insecure assets.
Test mixed content and redirects
After SSL is enabled, browse the application and check whether any images, scripts, or stylesheets still load over HTTP. Mixed content can break browser warnings and make a production site look unfinished or insecure.
Review application configuration files
JSP applications often rely on external configuration for database connections, API keys, mail servers, caching, or environment-specific URLs. Before going live, review these values carefully.
Switch from staging to production values
Check that the application is using the production database, production endpoints, and live credentials where required. Many deployment issues happen when a site is published correctly but still points to a staging database or test API.
Common settings to review include:
- database host, name, username, and password;
- SMTP and mail delivery settings;
- external service URLs;
- file upload directories;
- session timeout and cache settings;
- log file paths;
- timezone and locale settings.
Check file and folder permissions
JSP applications may need write access for logs, uploads, cache files, or generated content. At the same time, you should avoid giving unnecessary write access to the whole web root.
Before launch, confirm that:
- upload directories are writable;
- log directories are writable by the service account;
- configuration files are not publicly editable;
- file permissions are not too open;
- the application can create temporary files if needed.
If permissions are too strict, the site may fail when it tries to save uploads or write session data. If they are too open, you may expose sensitive files to modification.
Test logs before and after the switch
Plesk and Tomcat logs are some of the most useful tools when preparing a JSP site to go live. Review them before launch if possible, and again immediately after publishing the site.
What to look for in logs
Look for messages related to:
- application startup failures;
- class loading errors;
- missing libraries or JAR files;
- database connection problems;
- permission errors;
- wrong context path or 404 responses;
- port conflicts or service startup failures;
- SSL certificate warnings.
For a managed hosting setup, quick log checks often reveal whether the issue is in the application, the deployment structure, or the hosting configuration.
Test from a clean browser session
Once the application is live, open it in a private browser window or a clean browser session. This avoids cached redirects, stale cookies, and old session data that can hide configuration problems.
Test the following:
- homepage loads successfully;
- login works if the site has authentication;
- forms submit correctly;
- static assets load from the correct domain;
- admin pages are restricted if necessary;
- error pages behave as expected.
Common issues when a JSP site goes live
404 Not Found after deployment
This often means the context path, document root, or deployment directory is wrong. Confirm that the application is deployed to the path expected by Plesk and that the domain points to the correct location.
403 Forbidden on the live domain
A 403 can be caused by incorrect permissions, a missing index file, or a hosting configuration that does not allow access to the selected path. Check the file system permissions and hosting settings in Plesk.
Application does not start
If the site loads but the app server does not start the application, check the Tomcat logs, Java version, and library dependencies. A mismatch between the build and runtime environment is a common cause.
Database connection errors
These usually come from wrong credentials, the wrong JDBC driver, or a production database that is not reachable from the hosting account. Verify the connection string and confirm that the production settings are active.
Styles or images are missing
This may happen if static files were deployed to the wrong folder or if links still point to a staging domain. Check relative paths, absolute URLs, and the final document root.
Practical launch checklist for Plesk JSP hosting
Use this quick checklist just before switching traffic to the live site:
- Confirm the correct domain and subdomain are active in Plesk.
- Verify the hosting settings and document root.
- Check that My App Server or Tomcat is enabled and running.
- Select the correct Java version.
- Confirm the Tomcat version matches the application requirements.
- Deploy the final WAR or application folder.
- Review the context path and public URL.
- Install the SSL certificate.
- Force HTTPS if required.
- Switch configuration files to production values.
- Check writable directories and permissions.
- Review logs after deployment.
- Test the site in a clean browser session.
When to use a staging site first
If your JSP application has database connections, file uploads, authentication, or custom servlets, it is a good idea to test it on a staging subdomain first. This helps you verify that the Plesk hosting settings, Java runtime, and Tomcat deployment behave correctly before real users visit the site.
A staging environment is especially useful when:
- you are changing Java versions;
- you are moving from a development server to shared hosting;
- you are deploying a new WAR build;
- the app uses external APIs or payment providers;
- you need to confirm SSL redirects and session behavior.
After the staging version is stable, you can move the same configuration to the live domain with less risk.
FAQ
Do I need Tomcat enabled before publishing a JSP site?
Yes. A JSP application needs a servlet container such as Tomcat or your hosting provider’s Java service. If the service is not running or not assigned to the domain, the application will not work correctly.
Should I use the same Java version in staging and production?
Yes, if possible. Using the same Java version in both environments helps you avoid compatibility surprises after launch. If a change is required, test it before switching traffic.
Can I put a JSP site live directly from the Plesk panel?
In many hosting setups, yes. If your account includes Java hosting through Plesk and My App Server, you can often deploy the application, configure the domain, and manage the service from the control panel.
What is the most common reason for a JSP site failing after launch?
Common causes include the wrong context path, a Java version mismatch, missing libraries, incorrect permissions, or database settings that still point to staging.
Do I need HTTPS for a JSP site?
For most public websites, yes. HTTPS protects logins, forms, and session cookies, and it is a standard part of a production hosting setup.
What should I check if the site works in testing but not on the live domain?
Review the domain binding, document root, context path, SSL certificate, and production configuration values. Also check logs for startup errors or redirect issues.
Conclusion
Preparing Plesk before putting a JSP site live is mostly about making sure the hosting settings, Java runtime, Tomcat service, and application files all match the production domain. When these pieces are aligned, launch day is much smoother and troubleshooting becomes easier.
For JSP hosting through Plesk, especially with a managed Java setup such as My App Server, the safest approach is to verify the domain settings, select the correct Java and Tomcat versions, deploy the final application build, secure the site with HTTPS, and review logs immediately after go-live. That gives your JSP application the best chance of starting cleanly and staying stable for users.